AIが45分でウェブサイトを公開した日｜GPT-6 Astraに架空フェスの公式サイトを作らせて、制作会社の代表が全機能を検証してみた

• ChatGPT
• AI
• WEBデザイン
• ホームページ制作
• 地方中小企業

指示を1回送って、席を立ちました。

戻ってきたら、ウェブサイトが公開されていたんです。

トップページも、出演者一覧も、3日分のタイムテーブルも、チケットの比較も、FAQも。URLを開けば、私以外の人にも見られる状態で、そこにありました。私がやったことは、最初の指示文を書いて送信ボタンを押しただけ。その間、コードは1行も書いていないし、デザインの修正指示も、公開作業も、一度もしていません。

かかった時間は約45分です。

ウェブ制作を生業にしている会社の代表として、これは正直、しばらく画面を見つめてしまう出来事でした。同時に「じゃあ我々の仕事はどうなるの？」という話でもある。なので今回は、できあがったサイトを私自身が1機能ずつ実際に触って検証した結果を、良かったところも足りなかったところも含めて、全部書きます。

実物はこちらです。今も公開しています。

• NEON HARBOR 2027（架空の音楽フェス公式サイト）

何をやったのか：指示は1回、あとは放置

使ったのは GPT-6 Astra です。OpenAIが2026年9月3日（米国時間）に発表した最新のフラッグシップモデルで、私はその「ウルトラモード」、つまりいちばん深く考えさせる設定で走らせました。

（この「ウルトラモード」という呼び方について、正確なところを補足します。OpenAIの開発者向けドキュメントでは、思考の深さ（reasoning effort）に指定できる値として none / minimal / low / medium / high / xhigh / max が挙げられていて、どの値が使えるかはモデルごとに違います。 GPT-6 Astraについては「none は使えない」と明記されています。一方、公式のシステムカードには、社内評価で「Ultra reasoning effort」を使ったという記述も出てきます。つまりChatGPTの画面表記と開発者向けの名称は、そのまま対応しているわけではありません。ここは「いちばん深く考えるモードで動かした」と理解してもらえれば十分です）

指示文はこれです。長いですが、そのまま載せます。ここが今回のいちばん大事な部分なので。

読み返してもらうと分かるんですが、この指示、デザインの話をほとんどしていません。 色も、フォントも、レイアウトも指定していない。「かっこよくして」すら言っていません。

代わりに書いたのは「誰のためのサイトか」「何ができないと困るか」「守ってほしい条件は何か」です。これは要件定義書の書き方であって、デザイン発注の書き方ではないんですね。ここが今回の実験の肝でした。

できあがったもの：18組・3ステージ・3日間

45分後、こうなっていました。

トップページです。夕暮れの港の写真に「NEON HARBOR」の巨大なタイポグラフィ。日付、会場名、そして「3 DAYS / 3 STAGES / 18 ARTISTS」のスタンプ。

サイト全体の規模を数えると、こうなります。

出演者は全員架空です。LUMA KIDS、NAMI.wav、THE AFTERHOURS……といった名前が18組。それぞれに「放課後のガレージから、海沿いの大きなステージへ」といった紹介文と、キャッチコピーと、イメージカラーが割り当てられています。会場は「凪浜・ミナト・コモンズ」、最寄りは「ミナト・コモンズ駅」。全部作り物です。

そして中身を覗いてみると、実装はこうなっていました。

• app.mjs（JavaScript）約47KB
• styles.css 約55KB
• data.json 約12KB（出演者・日程・ステージ・FAQ・チケットの全データ）

注目すべきは、データとコードが分かれていることです。 出演者情報はJavaScriptの中に直書きされておらず、data.json という別ファイルから読み込む構造になっている。つまり出演者が1組増えても、JSONに1ブロック足すだけで済む。フレームワークもライブラリも一切使わない素のJavaScriptで、そこまで組んでありました。

実際に全機能を触って検証しました

ここからが本題です。「AIがサイトを作った」という話は世の中に溢れていますが、本当に動くのかを1つずつ確認した記事はあまり見かけないので、私が全部やりました。ブラウザを自動操作して、実際にボタンを押し、値を入れ、画面の状態を確認しています。

① ジャンル絞り込み：動く

「ALL GENRES / Indie Rock / Electronic / Hip-Hop / R&B / Alternative」のボタンが並んでいます。Electronicを押すと、4組に絞り込まれ、上部の件数表示も「4 ARTISTS / 全18組」に変わりました。

地味ですが大事なのは、この件数表示に aria-live="polite" が付いていたことです。これは何かというと、画面が読めない人がスクリーンリーダーを使っているとき、「4件になりました」と読み上げてもらうための指定なんですね。押した結果が音声で伝わる。これ、人間が作っても抜けがちな部分です。

日程での絞り込み、キーワード検索、「お気に入りだけ表示」も同じように動きました。3つを重ねがけしても、件数は正しく変わります。

①-2 お気に入り登録：押した状態がブラウザに残る

ハートのボタンも押してみました。押すと「LUMA KIDSをお気に入りに追加しました。」とトーストが出て、ボタンの状態（支援技術に伝わる aria-pressed）が false から true へ切り替わります。「お気に入りだけ表示」で絞ると、ちゃんと1件。

そしてページを再読み込みしても、押した状態は残っていました。 ブラウザの中に保存されているからです（この保存方式の限界は、後半で正直に書きます）。

② 検索結果ゼロ：ちゃんと用意されている

存在しない文字列を入れてみました。出てきたのがこれです。

まだ出会っていない音が、あるかも。

条件に合うアーティストが見つかりませんでした。

キーワードやジャンルを変えて探してみてください。

［絞り込みをリセット］

「0件です」で終わらせず、次にやることを提示して、その場で戻れるボタンまで置いてある。 しかも文言がサイトの世界観に沿っている。ここは私が指示文に「検索結果なしの表示」と1行書いただけの部分です。

③ 予定の重複警告：ここがいちばん驚いた

タイムテーブルから、わざと時間が重なる2公演を選びました。DAY 01 の LUMA KIDS（18:00–19:00）と NAMI.wav（18:30–19:30）です。

まず、2組目を追加した瞬間に画面下へこう出ました。

NAMI.wavを予定に追加しました。 時間が重なっています。MY FES で確認できます。

そしてMY FESを開くと、警告ボックスがこう出ます。

観たいライブの時間が重なっています

両方を予定に残せます。観る公演を選ぶ場合は、下の「追加済み」ボタンで予定から外せます。

・DAY 01 · 18:30–19:00 LUMA KIDS ＋ NAMI.wav

見てほしいのは 「18:30–19:00」 の部分です。重なっている時間帯そのものを計算して出している。「重複しています」と言うだけなら簡単ですが、実際に何分かぶるのかを示すかどうかで、ユーザーの判断は変わります。30分の重なりなら「前半だけ観て移動する」という選択ができるので。

さらに感心したのが、勝手に片方を消さないという設計判断です。「両方を予定に残せます」と明示したうえで、外し方だけを案内している。予定表の上部には「2公演を予定 / 0お気に入り / 1時間の重複」というカウンターも出て、重複の数字だけ赤くなります。

そして注記にこう書いてありました。

保存先は現在のブラウザーです。別の端末とは同期されません。カレンダー保存は .ics 形式で、予定の日時は日本時間です。移動時間は重複判定に含まれません。

「移動時間は重複判定に含まれない」。これ、私は指示していません。でもフェスの現場では、ステージ間の移動で10分かかるから実質かぶる、というケースが山ほどある。 その但し書きを自分で書いている。ついでに言うと、別ページには「各ステージ間は徒歩約5〜10分。移動や休憩の時間も見込んで予定を組みましょう」とも書いてありました。

④ 読み込み中・エラー表示：デモとして体験できる形にしてある

「読み込み中の表示とエラー表示も作って」と指示したんですが、これって普通、通信を失敗させないと見られないんですよ。開発者ならブラウザの開発者ツールでオフラインにして確認しますが、一般の人には無理です。

Astraの答えはこうでした。フッターの「このデモについて」を開くと、モーダルの中に ［読み込み中の表示］［エラー時の表示］というボタンが2つ置いてある。 押すと、その画面が再現されます。

エラー画面はこうです。

情報を読み込めませんでした。

これはエラー表示のサンプルです。保存した予定は保持されています。

［もう一度読み込む］

お気に入りや保存済みの予定は削除されません。

「あなたのデータは消えていません」を先に言う。エラー画面でユーザーがいちばん不安になるのはそこなので、正しい判断です。

ちなみに実装を見たら、データ読み込みには10秒のタイムアウトが設定されていて、受け取ったデータの形式チェックまで入っていました。壊れたデータが来たらエラー画面に落とす、という作りです。

⑤ スマホ・タブレット対応：画面幅ごとに別レイアウトを持っている

iPhoneサイズ（幅390px）で開きました。タイムテーブルは、ステージ別のグリッド表示から時間順のリスト表示へ切り替わります。 単にレイアウトが縮んだのとは違います。 しかも画面には「スマートフォンでは公演を時間順に表示します」と一言書いてある。

メニューはハンバーガーボタンに変わり、開くとフルスクリーンのナビが出ます。Escapeキーで閉じられて、閉じたあとフォーカスがボタンに戻る。この「戻る」まで実装されているのは、正直かなり丁寧です。

タブレット幅（768px）も測りました。こちらは3ステージ分の列を保ったグリッド表示のままで、1列あたり約210px。横スクロールは発生しませんでした。スマホ用の注記も非表示になっています。画面幅ごとに、見せ方そのものを切り替えているわけです。

⑥ キーボード操作：Tabで回れる

Tabキーを9回押して、フォーカスがどこにあるか確認しました。ヘッダーのリンクを順に通って、ジャンル絞り込みの「R&B」ボタンに到達。フォーカス位置が視覚的にはっきり分かる枠で示されます。

ページ最上部には「本文へスキップ」リンクもありました。これはキーボードで使う人が、毎回ヘッダーのメニューを全部通らずに本文へ飛べるようにする仕組みです。表示上は見えず、Tabを押した瞬間だけ現れます。

⑦ 文字コントラスト：実測しました

「十分なコントラスト」と指示したので、数値を測りました。

対象	コントラスト比	基準
本文テキスト（濃灰 on 生成り）	13.66 : 1	AAA（7:1）を大きく超過
黒ボタンの白文字	13.66 : 1	AAA超過
オレンジボタンの文字	5.39 : 1	AA（4.5:1）クリア
注記の小さい文字	5.21 : 1	AAクリア

WCAG（ウェブアクセシビリティの国際指針）のAA基準が4.5:1、AAA基準が7:1です。本文は13.66:1。狙って作っていないと出ない数字です。

⑧ 動きを減らしたい人への配慮：CSSとJSの両方に入っていた

OSの設定で「視差効果を減らす」をオンにしている人向けの prefers-reduced-motion という指定があります。これがCSS側で全アニメーションとトランジションを止めるように書かれていたのは、まあ想定内でした。

驚いたのはJavaScript側です。ページ内リンクでスクロールする処理に、この設定を見て「なめらかスクロール」と「一瞬で移動」を切り替える分岐が入っていました。CSSだけ対応して満足せず、スクリプトの挙動まで揃えている。

⑨ 機械的なアクセシビリティ検査：5ページ中4ページが違反0件

業界標準の検査ツール（axe-core）を主要5ページに走らせました。結果です。

自動検査で拾えるのはアクセシビリティ課題の一部であって、これで満点という意味ではありません。それでも、人間が数日かけて作ったサイトを検査して0件で返ってくることは、実務ではそう多くないです。指摘された1件も、見出しの階層が1段飛んでいるという軽微なもので、修正は5分もかかりません。

指示していないのに入っていたもの

ここまでは「指示したことができていた」話です。私が本当に唸ったのは、言っていないのに入っていたものの方でした。

最後のは、指示文に「初めてフェスに参加する人にも使いやすいサイトに」と書いただけです。そこから会場アクセスのバリアフリー情報まで書いている。

そして「架空であること」の明記は、サイト内の3か所に、それぞれ文脈に合わせた言葉で入っていました。

• チケットページ：「架空のフェスのため、実際の購入・決済は行われません。プラン選びを体験できます」
• アクセス案内：「これは架空の交通案内です。駅名・路線・住所は実在の経路検索には使えません」
• JavaScriptを切った人向け：「本サイトは架空の音楽フェスのデモです」

1か所にコピペで済ませず、その画面で誤解が起きうる内容に合わせて書き分けている。 実在の経路検索に使えない、という但し書きは、私は思いつきませんでした。

3体のAIが分担して、しかも互いに検品していた

さて、ここからが個人的にいちばん面白かった部分です。

私は普段から、AIエージェントとその子エージェントの動きを可視化する自作ツールを動かしています。名前は「MOCHI OPS（もち管制室）」。誰が何をしていて、どれくらい時間が経っていて、どのツールを何回叩いたのかが1画面で見えるものです。今回の制作中も、これを起動していました。

まず、作業の途中の画面がこちらです。

親の「ORCHESTRATOR」がいて、そこから子エージェントが枝分かれしています。1つの依頼が、内部で複数の担当に分かれて同時に走っている。 人間の制作現場でいえば、ディレクターが情報設計とデザインを別の担当に振っている状態とまったく同じです。

そして、こちらが完了時の画面。ここに全部の記録が残っていました。

右側のイベントログを書き出すと、こうです。

経過	できごと
00:00.0	Lagrange 誕生 — festival_data（フェスのデータ設計）
01:16.9	Anscombe 誕生 — artist_art（アーティストのアートワーク制作）
20:56.0	Raman 誕生 — browser_qa（ブラウザでの品質確認）
23:40.4	Anscombe 帰還 — 1,343.6秒 / 909,234トークン / ツール12回
29:19.9	Lagrange 帰還 — 1,760.0秒 / 2,252,514トークン / ツール27回
31:24.4	Raman 帰還 — 628.4秒 / 2,827,732トークン / ツール36回

親エージェント自身は2,088.4秒（約35分）稼働し、ツールを49回実行。最終的に「AGENTS 3 / RESULTS 3 / COMPLETE」で終わっています。

数字を足すと、子3体だけで約599万トークン、ツール実行は親子合わせて124回。 私が指示文を1回書いた裏側で、これだけのことが動いていたわけです。

ここで注目してほしいのは、3体目のRamanが「20分56秒後」に生まれている点です。最初からいたわけじゃない。データとアートワークが仕上がってきた段階で、検品担当が後から投入されている。 人間のディレクションとして、極めて自然な順序です。

AIが「残り1件、バグがあります」と正直に報告していた

いちばん唸ったのはここです。データ設計を担当したLagrangeの最終報告に、こう書かれていました。

（前略）実装の主要指摘と artist-name 固有フォーカスは修正済みです。新たな重大不具合はありません。残る1点：app.mjs:128,210 の別タブ同期時、開いたモーダルを再描画後に背面ボタンへ復帰しようとします。restoreFocus() はモーダルが開いている場合、その内部を検索対象にすると解消

かみ砕くと、こういう話です。

「2つのタブでサイトを開いていて、片方でモーダル（詳細ポップアップ）を開いたまま、もう片方で予定を変更すると、画面が再描画されたときにフォーカスがモーダルの外側のボタンへ飛んでしまう」——キーボードやスクリーンリーダーで使っている人にだけ影響する、極めて細かい不具合です。

そして、この報告が本当か、私は公開されているコードで確認しました。

restoreFocus() の実装がこうなっていました。

const scope = $('#modal').open ? $('#modal') : document;

モーダルが開いていれば、探す範囲をモーダルの中に限定する。 Lagrangeが「こうすれば解消する」と書いた対策が、そのまま実装されて公開されていたんです。ついでに「閉じているダイアログの中の要素は除外する」という条件まで足されていました。

これ、AIと仕事をするうえで本当に大事なポイントだと思っていて。「できました」ではなく「ここまでできて、残りはこれで、対策はこうです」と報告してくる。 そのうえで直っている。私が普段、人間のスタッフに求めているのとまったく同じ報告の形です。

「実測」と「推定」を書き分けること

もう1つ、この画面には見逃せない表示があります。進捗バーの横の注記です。

• 完了した仕事：「実測で確定」
• 走っている最中の仕事：「推定（ツール実行回数ベース）」

終わった数字は実測、途中の数字は推定と、はっきり書き分けてある。 自作ツールなので手前味噌になりますが、AIの進捗表示でいちばん危ないのは「85%完了」みたいな根拠のない数字を信じてしまうことなんですね。だから「これは推定値です」と顔に書いておく。

AIに仕事を任せるなら、AIの申告をそのまま信じない仕組みを、こちら側に持っておく。 今回、Anscombeの「15組すべてにアートワークを作りました」という報告を、私が実際に15ファイル取得して確認したのも同じ理屈です（結果は全部実在しました）。この記事で数値を全部測り直したのも、同じ理由です。

なお、この2枚は撮影したタイミングが違います。経過時間の数字を並べて「何分後にこうなった」と読まないでください。見てほしいのは時間ではなく、1つの依頼が複数の担当に分かれ、作られ、検品され、残課題まで報告されているという構造の方です。

ちなみに、AI同士が連携して動く仕組みそのものについては、AIが勝手に別のAIへ連絡を始めた話という記事でも書きました。今回はそれが実務の成果物として出てきた形です。

プロとして見た「足りないところ」

ここまで褒めてきましたが、ウェブ制作を仕事にしている立場として、そのまま納品はできません。実測した数字で3つ挙げます。

1. 画像が重い

トップページの初回読み込みで 6.86MB 転送されていました。内訳を測ると、原因ははっきりしています。

種類	枚数	合計サイズ
PNG画像（メインビジュアル＋出演者3組）	4枚	8.97MB
SVG画像（出演者15組＋アイコン）	16枚	211KB
コード＋データ（JS・CSS・HTML・JSON）	4ファイル	114KB

プログラムは114KB、画像は約9MB。 桁が2つ違います。1枚2〜2.6MBのPNGがそのまま置かれている状態です。

これ、実務なら真っ先に直す部分です。WebPやAVIFという軽い形式に変換して、表示サイズに合わせて縮小すれば、画質をほとんど落とさずに10分の1以下になります。スマホの電波が弱い会場周辺で開くサイトとしては、致命的とまでは言わないまでも、確実にマイナスです。

（弁護しておくと、体感速度自体は悪くありません。最初の描画は0.3秒で始まっていました。画像は後から順に読む作りになっているので、真っ白な画面を長く見せられるわけではないんです。それでも通信量は通信量です）

2. 文字が小さい箇所がある

コントラストは満点でしたが、サイズは別問題です。注記の文字が10px、ラベルの英字が8pxで組まれている箇所がありました。

コントラスト比が5:1あっても、10pxの日本語は40代以降にはきついです。 私はシニア向けの生成AIセミナーもやっているので、この感覚には敏感なんですが、実案件なら12〜13pxまで上げます。国際指針に文字サイズの数値規定はないので「違反」ではありません。でも「読めるか」は別の話です。

3. データがそのブラウザの中にしかない

お気に入りも予定も、そのブラウザの中だけに保存されます。スマホで作った予定は、PCでは見られません。 サイト自身が「別の端末とは同期されません」と正直に書いているので隠してはいませんが、本番のフェスサイトなら会員登録とサーバー側の保存が要ります。

つまり、ログインが必要なもの、データベースが要るもの、決済が絡むものは、まだこの1発では出てこないということです。今回作れたのは「全員に同じものを見せて、各自の端末の中だけで完結する」タイプのサイトでした。

4. そして、いちばん大事なこと

中身がぜんぶ架空だから成立している、という点です。

今回、私は「出演者名も文章も画像も架空で作って」と指示しました。だからAIは自由に作れた。でも実案件では、載せる情報はお客様の中にしかありません。

サービスの強みは何か。誰に届けたいのか。過去に何を言われて、何がうまくいかなかったのか。競合と何が違うのか。この取材と整理こそが、我々が時間をかけている部分の本体です。AIは「もっともらしい構造」を秒で出しますが、「御社にしか書けない一文」は出しません。そこは変わっていない。

で、「予算はないけどサイトはそれなりに」はどうなるのか

ここからが、ウェブ制作会社の代表としての結論です。

カンマンにはよく、こういう相談が来ます。

スタートアップで予算があまりない。でもサービスの顔になるサイトは、それなりのものを作りたい。

この2つは長いあいだ、両立しにくい要望でした。 クオリティを上げようとすれば工数が増え、工数が増えればコストが上がる。当たり前の話です。制作側にとっても、発注側にとってもジレンマでした。だから「知り合いのデザイナーに個人的に頼む」といった形で折り合いをつけてきたケースも、実際は多かったと思います。

今回の45分は、その前提が変わったことを示しています。

「そこそこのクオリティで十分」という要望なら、専門家でなくても、これくらいのものは作れる。公開まで持っていけるし、独自ドメインを当てることもできる。

これは脅しでもポジショントークでもなく、実際に自分でやってみて出た結論です。

念のため補足すると、今回使ったChatGPTのサイト公開機能（ChatGPT Sites）は、2026年9月時点でパブリックベータです。無料プランとGoプランを除く有料プランで順次提供されていて、独自ドメインの接続もできます（ドメイン自体は自分で取得してDNSを触る必要があります）。だから「誰でも今日から」ではありませんが、月額数千円のプランの延長線上にある、という距離感です。

じゃあ我々の仕事がなくなるのかというと、私はそうは思っていません。変わるのは「お金を払う場所」だと思っています。

紹介用のLPを1枚。まず初期の公式サイトを立ち上げたい。この手の依頼は、正直、自分で作ってしまった方が速い時代です。 そう言える会社でありたいと思っています。

一方で、問い合わせが売上に直結するサイト、複数人で更新し続けるサイト、決済や会員情報を扱うサイトは、話が別です。ここは「作る」より「作った後」に価値の重心がある。今回のサイトも、公開はできましたが、来月データを差し替えるのは誰か、表示が崩れたら誰が直すのか、という問いには答えてくれません。

私たちがこれから提供するのは、たぶん「制作」ではなく 「判断と運用」 です。何を載せるべきかを一緒に決めて、AIに作らせるところは作らせて、人間が見るべきところを見る。今回の検証で私がやった作業——実際に全機能を触って、数値を測って、足りない部分を specific に指摘する——これがまさに、これからの制作会社の仕事だと思っています。

AIに作らせるとき、うまくいく指示の書き方

最後に、成果をいちばん左右したと思うポイントを書いておきます。真似できる部分なので。

特に3つ目です。アクセシビリティは、後から足すほど工数が膨らみます。 最初の1行に入れておけば、AIは最初からその前提で組んでくれる。人間の制作現場でも、事情はまったく同じでしょう。

そして4つ目。「作って」で終わらせず「確認して、直してから報告して」と書く。今回、子エージェントの1体が実際にブラウザでの品質確認を担当していたのは、この1文があったからです。

指示文を1行増やすだけで、成果物の質が変わる。 これはAI活用の研修でも毎回お伝えしていることですが、今回ほどはっきり効果が見えた例はありませんでした。

よくある質問

Q. 本当に一度も修正指示を出していないんですか？ はい。最初の指示文を送ったあと、公開されるまで私は何も入力していません。ただし、これは「毎回こうなる」という意味ではありません。題材が架空で、外部サービスとの連携がなく、データも自前という条件が揃っていたことは大きいです。

Q. 無料でできますか？ できません。GPT-6 AstraはChatGPTのPlus以上のプランが対象で、サイト公開機能も無料プランとGoプランは対象外です（2026年9月時点、パブリックベータ）。とはいえ月額数千円の話です。

Q. 会社の本番サイトをこれで作っていいですか？ 「まず出す」ためのものとしてはアリだと思います。ただし今回検証したとおり、画像の最適化、文字サイズ、データの持ち方など、公開後に人の手で直すべき点は残ります。 問い合わせや採用など成果に直結するサイトなら、設計と運用は専門家を入れてください。

Q. デザインは本当に「それなり」でしたか？ 私の評価は「小規模な制作会社が数日かけて作る水準には届いている」です。特にタイポグラフィの使い方と余白の取り方は素直に上手い。ただし他社と並べたときの独自性、つまりブランドを差別化する部分は、まだ人間の領域です。

Q. 徳島の中小企業でも使えますか？ 使えます。むしろ、社内に制作担当がいない会社ほど恩恵が大きいはずです。まずは社内向けのページや、イベント告知の1枚ものから試すのがおすすめです。カンマンでは生成AIの活用研修もやっていて、研修の効果をどう測るかという話も書いています。「自社で何ができるか整理したい」という段階からご相談いただけます。

まとめ：45分の意味

今回いちばん伝えたいのは「AIがすごい」ではありません。

指示を1回送っただけで、実際に触れるウェブサイトが公開された。 その事実は、「サイトを作る」という行為のコストが、私たちが慣れ親しんできた水準から明確に下がったことを意味します。

だからこそ、聞くべき問いが変わります。「いくらで作れますか」ではなく、「これは自分で作るべきものか、プロに頼むべきものか」です。

その判断は、正直、業者に聞くと利益相反があります。だから私はこう言うようにしています。自分で作れるものは、作ってしまってください。 そのうえで「これは自分たちだけだと無理そうだ」と思ったときに、声をかけてもらえればいい。

その方が、お互いに幸せだと思うんですよ。

実物のサイトは公開しています。スマホでもPCでも触れるので、まずは自分の指で確かめてみてください。予定を2つ重ねて、警告が出るところまでやってもらうのが、いちばん面白いはずです。

• NEON HARBOR 2027 を見る（すべて架空の内容です）

そして「うちの場合はどうだろう」と思われたら、お気軽にご相談ください。作る前の整理からお手伝いします。

• カンマンに相談する

参考・出典

• OpenAI「GPT-6 Astra: A new generation of intelligence」（2026年9月3日）https://openai.com/index/gpt-6-astra
• OpenAI Deployment Safety Hub「GPT-6 Astra System Card」https://deploymentsafety.openai.com/gpt-6-astra
• OpenAI API ドキュメント「Reasoning models」（思考の深さの設定）https://developers.openai.com/api/docs/guides/reasoning
• OpenAI Help Center「ChatGPT Sites の作成と管理」https://help.openai.com/ja-jp/articles/20001339-creating-and-managing-chatgpt-sites
• ChatGPT Learn「Sites」https://learn.chatgpt.com/docs/sites

あわせて読みたいカンマンのコラム

• AI活用の記事一覧
• ホームページ制作の記事一覧
• Claude Codeの設定を棚卸しした話

本文中のサイトに関する数値（ファイルサイズ、コントラスト比、読み込み時間、アクセシビリティ検査の結果、機能の動作）は、すべて2026年9月6日に筆者が公開サイトに対して実測したものです。