GPT-6 Astraと進めた、月曜日のトラのサイト改修日記

最初に、少しお詫びです。ブログのアイキャッチ画像の「4日でサイト公開」についてです。事実ではあるのですが、実際にはそこから細かな調整を入れまくりました。壮大な釣りタイトルになっていてすみません。

9月7日に始めて、10日には公開できました。ただ、そこから細かな調整が続き、まずまず納得したのは14日。公開まで4日、そこからさらに4日。この記事は、その後半の工程も含めたサイト改修日記です。

月曜日のトラは、データとテクノロジーに強みを持つマーケティング支援会社です。Web制作者ではない私が、AI「GPT-6 Astra」と自社サイトを改修した記録です。

使ったのは、CRMと、文章や画像を管理するCMSを備えたHubSpotです。既存サイトと会社の資料を使い、改修を進めました。

9月28日（月）12:00から無料オンラインセミナーも開催します。詳細・お申し込みはこちら。

AIでのサイト制作で確かめたかった3つのこと

今回、AIでのサイト制作で確かめたかったのはこの3つです。

1. AIと画面を見ながらやりとりすれば、自分が使いたいと思えるサイトまで持っていけるか
2. 見た目だけでなく、CMSの編集用部品も扱えるか
3. 会社の資料を渡せば、自社の仕事が伝わる内容に変えられるか

実際やってみて、AIと画面を見ながら注文を重ね、4日で公開、8日でまずまず納得できるところまで進められました。CMSの編集用部品も扱えましたし、会社の資料を使うことで、私たちの仕事が伝わる説明にも近づけられました。

実は、最初から検証項目をきれいに決めていたわけではありません。「これ、できるのでは？」というノリで始めています。振り返って、期待していたことと実際の結果をまとめるとこうなります。

細部の確認と、蓄積した情報の活用も課題になった

ほかにも、次のことがわかりました。

• 全体を形にした後の細部に、思った以上に手間がかかる。
  • 見出しの改行、メニューの間隔、フォームの読み込みなど、公開後も確認と修正が続きました。
• 蓄積したコンテンツは、原稿だけでなくレビューにも使える。
  • 私たちのアナリスト・梶井の登壇資料を読むAIのサブエージェント「kajii」には、説明に抜けた視点も指摘してもらいました。
• CRMの取引記録も、サイトの材料になる。
  • HubSpotの顧客管理データから、メンバー紹介に載せる経験業種を整理できました。
• 専門役を分けると、見落としを拾いやすい。
  • 文章、動き、情報設計、使いやすさなど、AIに見る観点を分けて依頼しました。
• 制作の速さを活かすには、人の判断も必要。
  • 今回は決定権を持つ私がその場で注文できました。確認待ちの多いクライアントワークで、同じ速さになるとは限りません。

具体的な経緯は、8日間の試行錯誤とともに後述します。

なお、今回はあくまで既存サイトのコードや記事、フォーム、会社の資料を活用した改修です。ゼロからの新規制作ではなく、集客や問い合わせが増えたかを検証したものでもありません。

1日目は見た目はどこまで変わるかの実験

きっかけは、知人から「GPT-6 Astra、使った？」と感想を聞かれたことでした。まだ触っていなかったので試してみると、AIがブラウザを操作してくれます。ボタンを押し、画面を移動し、入力する。このBrowser Useと呼ばれる動きが、私にはとてもスムーズに感じられました。

これならHubSpotを操作して、月曜日のトラのサイトも大きくアップデートできるのではないか。どこまでできるか試したくなり、マーケティング責任者の岩永に社内チャットで連絡しました。

最初に渡したのは、既存サイトのコードとページごとの情報です。HubSpotには記事やフォーム、編集用の部品があり、ロゴや伝えたい言葉も揃っていました。何もないところからではなく、今あるサイトをよくする試みです。

今のページは壊さず、トップとサービスページの別案を作ってほしいと頼みました。出てきた案は予想以上にクールでした。これはかなりできそうだという手応えがありました。

Webサイトの動きは、専門役にも意見を求めて作り直す

今どきのサイトのようにアニメーションを置いてみたい。ただ、トップのアニメーションはAIに作らせて実装してみるとなかなかしっくりきません。何度か直しても違和感が残るので、ゼロベースで考え直してもらいました。動きを考える仮想のMotion Designer、見せ方を考える仮想のArt Directorにも意見を求めています。これは人を追加で呼んだのではなく、担当を分けて考えさせるAIのサブエージェントです。海外のデータ系支援会社のサイトを参考に、奥行きを感じる表現へ進めました。

案がすぐ出てくるので、実物を見てから次の指示を出せます。頭の中のイメージを最初にすべて言葉にするより、「この案のここが違う」と伝えるほうが、私には進めやすかった。公開中のページを残して別案を作ったことで、元の状態と比べながら判断できたのも助かりました。

作ってもらい、実物を見て、また直す。AIとの往復で形を詰めていく。

この日の制作・改修：トップとサービスページのデザイン別案、トップのアニメーション案。まずは比較できる形を作りました。

2日目は実権をトップ以外に広げた結果、サイトの使いにくさが見えた

トップで手応えがあったので、他のページも試してもらいました。申し込みまでの流れを考えるGrowth Consultant、記事の構成や見せ方を考えるEditorial Designerというように、ここでもAIのサブエージェントに専門役を割り当てています。見栄えを整える役だけでは、ページごとの目的まで見落としそうだったからです。

しかし、申し込みページ、記事、会社概要など、それぞれ使われ方が違います。トップの見た目をそのまま移すだけではすみませんでした。

その後の調整では、長い申し込みフォームをページ下部へ移したり、お問い合わせには通常のヘッダーとフッターを戻したりしました。

GA4（Googleアナリティクス4）の設定診断の画面では、ドラッグ操作と拡大操作が競合してドラッグできなかったため、拡大は外してよいと頼みました。

機能を増やせば使いやすくなるわけではなく、実物を触って初めて気づくこともあります。

会社概要の言葉と、更新用の部品を見直す

会社概要では「土台が狂っていたら、全て狂う。」という文言がありました。会社の基本情報を知りたい人には、「いや、そんなこと言われても……」と思われそうです。ここには合わないと伝え、言い換えを依頼しました。所在地も会社情報と地図の付近で重複していたので、同じ情報を何度も見せないよう整理を頼んでいます。

実際にAstraに操作させて、HubSpotのモジュールまで扱えていることには驚きました。モジュールは、編集画面で文章や画像を変更できる部品です。見た目だけでなく、その後に人が更新する仕組みも残してほしかったので、ここまで扱えるのはとてもありがたいです。

月曜日のトラサイトをブラッシュアップしていってるけど、Astraがどんどん見栄えを整えていってくれている。弊社サイトはHubSpot Contents Hubで作っているけど、CMSをものともせず、かつモジュールをガン無視するわけでもなく構築していってくれているので恐ろしいです。…

— 西 正広 / (株)月曜日のトラ (@macchaice) 2026年9月8日

この日の制作・改修：申し込みページ・記事・会社概要の改修案と、HubSpotの編集用モジュール。トップ以外のページへ制作を広げました。

3日目はコピーライティングに手を入れる。短いコピーが、よいコピーとは限らなかった

見た目が整ってくると、今度は文章が気になります。月曜日のトラをどう説明するか。文章を校閲する仮想のCopy Editorにも見てもらいましたが、ここは何度も注文を出しました。整った文章が出てきても、それだけで私たちの仕事が伝わるとは限りませんでした。

文章は、この前後も何度か見直しました。たとえば、小さなラベルに「よくあるご質問」、その下の大きな見出しにも「支援範囲・期間・進め方の よくあるご質問」とあり、同じ言葉が続いていました。見出しだけで内容は伝わるので、重複するラベルはいらないと頼みました。ただ、重複を減らすことと、説明まで短くすることは別です。

技術の具体例が、相談できる仕事を伝える

私が残したかったのは、マーケティングとITの境界で実務を進めるチームとしての説明です。「CVR（コンバージョン率）改善のためのHTML・JavaScript、データ分析のためのPython・SQL、MA（マーケティングオートメーション）を活かすデータベース設計やIT部門との調整」。こうした具体的な技術や仕事の話があったほうが、何を相談できる会社なのかが伝わります。「マーケティングを支援します」とまとめてしまうと、私たちに頼む理由まで薄くなってしまいます。

ここでいうCVRは、サイトを訪れた人が申し込みなどに進む割合、MAはメール配信などのマーケティング業務を自動化する仕組みです。コードの名前を覚えてほしいわけではなく、「申し込みを増やすために画面も直す」「データを使うためにIT部門とも調整する」という、実務まで担う会社だと伝えたかったのです。

削りすぎた会社紹介文を戻す

トップの「マーケティングとITの間で、実務を前に進める。」という見出しの横に置く文章は、一度削りすぎていました。

「今の文章だと削りすぎて思いが伝わらない」と伝え、前の案と短くした案の間くらいの分量に戻してもらいました。

そのうえで、技術の具体例は残し、最後の一文を軽くするなど、文量と中身を別々に調整しています。私たちのステップメールも、そのまま転載するためではなく、月曜日のトラがどういう会社かを理解する材料として読んでもらいました。

長いから削る、ではなく、伝えたいことが残っているか。そこは画面と文章を行き来しながら注文しました。

この日の制作・改修：トップの会社紹介文と見出し・ラベルの修正版。技術や仕事の具体例を残しながら、文量と伝え方を調整しました。

4日目でAI制作のサイトを公開。最初の期待はどこまで実現したかの確認

サイトを公開しました。

月曜日に試し始めたものが、木曜日には公開できるところまで来ています。4日間でここまで変わったことをXにも投稿しました。この速さには驚きました。

今週月曜日からAstraができるやつだということを知り、月曜日のトラサイトのデザインリニューアルをかけました。わずか4日でここまで進化しました。
まだ細かいところを調整したいし、コンテンツの中身のブラッシュアップは必要なので、引き続きサイトを育てます。https://t.co/Zy7s3raJvE https://t.co/zMFmwB3wZt pic.twitter.com/7tBSKVuPbD

— 西 正広 / (株)月曜日のトラ (@macchaice) 2026年9月10日

ただ、全部の作業が終わったわけではありません。ロゴの表示、サンクスページ、フォーム、スマホの改行など、公開後にも修正を頼んでいます。

岩永からも指摘が入り、岩永が使う別のAI「Réti（実態はClaude Code）」とも確認を進めました。自分が見ていたページ以外にも、表示や設定の違いが残っていました。

公開ページで確認してから完了にする

コードの修正が取り込まれていても、本番サイトへの反映が済んでいないものがありました。それでは、何が終わっているのかわかりにくい。Linear（タスク管理ツール）とスプレッドシートに対応をまとめ、AIが実際のページを見て問題なければ完了にするよう依頼しました。

4日目までにできたことと最初の期待と比べるとこうなります。
AIとやりとりして、CMSの編集用部品を扱いながら、公開できるところまでは進められたのは予想以上でした。一方、「公開できる」と「納得できる」は同じではありませんでした。

会社の説明も、スマホ表示も、まだ直したい。ここからは、形になったサイトをどこまで自分たちのものにできるか、という試行錯誤に変わっていきました。

この日の制作・改修：ここまで作ってきたサイトの初回公開版。あわせて、公開後に直す箇所と確認状況をまとめる管理表も整えました。

5日目は自社らしい説明のために過去の資料を活用する

公開できたものの、サービスの説明はまだよくできそうです。見た目だけでなく、中身にも私たちの知識を使ってほしい。公開記事やセミナー資料、社内情報を読んでもらい、よくある質問や図も見直してもらいました。

データ基盤の図は、最初の案が分析に寄りすぎていました。月曜日のトラは設立当初はデータ分析の会社でしたが、いまはデータとテクノロジーに強みを持つマーケティング支援会社としています。

参考になりそうなセミナー資料を読んでもらい、データをつないで施策に使う仕組みとして描き直してもらいました。他社サイトだけでなく、私たちが説明してきた内容も使ってほしかったのです。

セミナーや提案のために作った資料が、サイトの文章や図の材料になる。

社内情報はそのまま公開せず、クライアント名や個人を特定できる情報は除くよう伝え、私も確認しています。

トップ以外を整える難しさも、この日に投稿しました。トップの印象が決まっても、他のページまで揃えるには、まだやることがありました。

さらに細かいところに手を入れていき、サイトはだいぶ整ってきた。トップの見た目が整っても、下層ページも合わせていくとか、各ページ間でサイト内リンクを貼っていくとかの細部へのこだわりの対応はそれなりに骨が折れますね。この土日で決着をつけたい。
ただ、AstraがあればHubSpot Contents… https://t.co/JRtFo6KI6x

— 西 正広 / (株)月曜日のトラ (@macchaice) 2026年9月11日

この日の制作・改修：セミナー資料をもとに描き直したデータ基盤の説明図と、サービス説明・よくある質問の修正版。蓄積してきたコンテンツを使い直しました。

6日目はスマホ表示に手を入れる。PCで整っていても安心はできない

スマホで見ていると、見出しが変なところで改行されていました。PCでは気づかなかったところです。こうした点検や修正も進めてもらい、調査には一律に高性能なモデルを使うのではなく、タスクの内容や難しさに応じて、対応できる軽量モデルを選んでほしいと伝えました。

一度直しても、別のページで似た問題が残っていることがあります。気づいた箇所だけでなく、同じスタイルが使われているところも調べてほしい、と頼む場面がありました。1カ所直ったことを、サイト全体が直ったことにしない。AIへの依頼にも、確認するページや画面幅まで含める必要がありました。

この時期には、私のChatGPTにブラウザ経由で質問する方法についても投稿しています。私や会社について蓄積された文脈を、別のAIからも参照できる使い方です。

Codexと私のChatGPTって繋げなくて、普段私がチャッピーに相談してる内容をうまく引っ張れないことにもどかしさがあったのだが、Astraでブラウザ操作させてチャッピーにプロンプト自動生成、回答回収させることにより私のメモリや相談内容を活かしたコンテンツが自動生成できる。これは革命的。

— 西 正広 / (株)月曜日のトラ (@macchaice) 2026年9月11日

何も知らない状態で文章を考えてもらうより、手元にある情報を使ってほしい。サイトのコードだけでなく、記事や資料、これまでの対話も材料にしてもらう進め方でした。

この日の制作・改修：スマホでの見出しの折り返しなど、表示の修正版。共通スタイルを使う他のページにも確認を広げました。

7日目はSEOと使いやすさを、別の観点から点検する

7日目と8日目はは、SEO（検索で見つけてもらうための改善）関連の対応を中心に進めました。サイトの見た目が整ってきたので、検索から見つけてもらい、訪れた人が必要な情報にたどり着けるところまで整えたい。ページの情報やリンク、表示速度など、公開後の細かな点検と修正を重ねています。

文章にも指摘を入れました。お問い合わせにあった「マーケティングを進めるための、データと技術の相談窓口。」というコピーは仰々しく感じ、「月曜日のトラへのお問い合わせ」くらいのシンプルな内容でよいと伝えました。サービスの価値を説明する場所と、連絡先を案内する場所では、必要な言葉が違います。

情報設計とアクセシビリティも点検する

この2日間には、情報の整理や配置を考えるIA（情報設計）、利用体験を考えるUX、操作のわかりやすさを見るユーザビリティの専門役も、AIのサブエージェントとして入れてほしいと依頼しました。情報をどの順番で見せるか、次にどこへ進めばよいかわかるか、スマホでも迷わず操作できるか。それぞれの観点から見直してほしかったのです。

アクセシビリティについても、WCAG 2.2に準拠するよう調整してほしいと頼みました。Webサイトの利用しやすさに関する基準です。文字の見やすさやキーボードでの操作など、見た目だけでは気づきにくい点も確認してもらう意図でした。これは調整の方針であり、サイト全体の適合を検証し終えたという意味ではありません。

共通部品の使われ方も確認してもらいました。トップでは動くカードが一覧では動かない、といった違いが残ると、同じ部品になっていないのでは、と気になります。

モジュールを作っただけで終わらず、実際のページがその部品に差し替わっているかも見てほしい。ページ単位の修正から、使われている場所全体の確認へ戻ることがありました。

違和感に応じて、AIの専門役を選ぶ

前日の9月12日には、どの専門役を呼ぶかに制作経験が出る、とも投稿しました。なんとなく微妙だと感じたとき、文章なのか、構図なのか、動きなのかを考えて、誰に意見を求めるかを決める。この部分には、それまでに見聞きしてきた知識が使われている感覚がありました。

「AIでWebサイト制作、ヤバいのでは」について、実際に自社サイトを作ってみて感じたこと。
今のところ、どんなサブエージェントを召喚するかに、Web制作者の経験やセンスが出る。
今回も、IA Consultant、Art Director、Motion Designer、Accessibility Reviewer、Editor、HubSpot…

— 西 正広 / (株)月曜日のトラ (@macchaice) 2026年9月12日

私はWeb制作者ではありませんが、出てきたものを見て注文することはできます。その注文を、別の専門役にも考えてもらえるところが面白いと思いました。

余談ですが、この日は日曜日でして、私もAIにつきっきりだったわけではありません。スマホから依頼を出し、息子とカブトムシの幼虫を育てる用事をしている間にも、自宅のPCで作業が進んでいました。ただし、戻ってから画面を見て判断するのは私です。任せられる作業が増えても、確認する時間までなくなったわけではありません。

この日の制作・改修：お問い合わせのコピーなど、文章や共通部品の見直し案。SEO・IA・UX・アクセシビリティの観点から、公開後の調整を進めました。

8日目は細部を詰め、次の更新に備える

引き続き、SEO関連の指摘をもとに、表示速度や読み込み時の問題を調べてもらいました。たとえば、フォームが大きなフォントファイルを追加で読み込んでいたり、一部のフォームで読み込みエラーが起きていたりしました。画面ができているように見えても、裏側ではこうした問題が残っています。修正後も、実際の公開ページで読み込みや表示を確かめてもらいました。

最初の数日で全体を作り、この2日間で、検索への配慮や情報の探しやすさ、操作のしやすさを詰めました。AIに専門役を呼んでもらうのも、こうした細部を別の観点から点検するためです。SEOの対応を進めたことと、検索流入が増えたことは別なので、この記事の時点で成果が出たとまでは言えません。ここで確認していたのは、修正後の表示や動作です。

次の更新に使うルールと名前を整える

ここまでできたものを、次の制作にも使いたいと思いました。テーマや共通部品だけでなく、今回伝えてきたルールも整理してもらいました。別の担当やAIに渡すたび、同じ注文を一から説明するのは避けたいところです。

用途のわからない名前も直してもらいました。コードなどにAstraの名前が残っている件は、Xでも触れています。作ったAIの名前より、何に使うものかがわかる名前のほうが、後から扱いやすいはずです。

AstraがHTMLのidやclass・CSS・JavaScript・画像名などにastra-xxxのような痕跡を残しまくっているので掃除している。Astra先生は自己顕示欲が強い。

— 西 正広 / (株)月曜日のトラ (@macchaice) 2026年9月14日

振り返ると、こちらの注文も途中で変わっています。実物を見てから、やはり戻したい、別の形を試したいと頼みました。AIが作る速さを、比較して考えるために使えた一方、確認する作業は続きました。検証まで指示する必要性は、早い段階から感じていました。

デジタルマーケターに伝えたいこととしては、Astraでbrowser useでGTM設定させるときに、指示しないと大抵プレビューモードによるデバッグの手順をすっ飛ばすので、そこはちゃんと伝えるとよきということでしょうか。逆に言えばちゃんと指示すればデバッグしてくれる。監督が必要ですね。

— 西 正広 / (株)月曜日のトラ (@macchaice) 2026年9月7日

既存サイトと会社の資料を渡し、AIに案を作ってもらい、私や岩永が見て、別のAIとも確認する。その往復でサイトが変わりました。何を残し、どこを直すかを判断し続けた8日間でもありました。

記事を書いている間も、改修は続く

なお、この8日間を振り返って原稿を書いている間も、サイトの改修を続けていました。この記録をまとめた9月14日の午後から夜にも、グローバルナビのサービスだけマウスを載せたときの色付き範囲が広い、サービスと支援実績の間だけ間隔が広い、といった点を直してもらいました。サービスページの関連記事が二重に出ていないか、コラムとサービスページでカードの見せ方が揃っているかも確認を頼んでいます。振り返りを書きながら、また気になるところを見つけて注文する。8日間は改修の区切りであり、すべての作業が終わった日数ではありません。

この日の制作・改修：フォームの読み込みやナビゲーションなど、細部の修正版と、次の制作にも使う共通ルール。関連記事カードの表示も確認しながら、仕上げを続けました。

HubSpotの受注データから、メンバーの経験を伝える

今回、HubSpotのCRMにある取引データも、サイトのコンテンツに活かしました。メンバー紹介に載せる「経験業種」の整理です。

受注済みの取引を取り出し、主担当と副担当の情報をもとに、各メンバーがどの業種の案件に関わっていたかを整理してもらいました。業種ごとにまとめ、該当する取引が多いものから掲載する形です。肩書きや自己紹介だけでは伝えきれなかった経験を、実際の取引記録から説明できるようになりました。

サイトに載せるのは、IT・SaaS、通信、教育といった業種名です。顧客名や個別の取引情報は出しません。また、担当者としての記録をもとにした整理なので、過去の経験をすべて網羅しているわけでもありません。

営業のために蓄積してきたデータが、会社やメンバーの経験を伝える材料にもなる。CMSとしてのHubSpotを使うことに加えて、CRMにある情報をサイト制作に使えたのは、今回の面白いところでした。

自社の専門家の資料を読む、サブエージェントを作成し活用する

専門家役の使い方でも、もう一つ試したことがあります。9月14日にCVR改善のサービスページを作る別タスクで、サブエージェントに「kajii」を加えました。月曜日のトラのアナリスト・梶井の登壇資料などを参照し、ページの説明をレビューする役です。梶井本人がその場でレビューしたという意味ではなく、資料に残っている知見をAIに読み取ってもらいました。

一般的なCVR改善の説明は、AIにも作れます。ただ、それだけでは、私たちが普段何を大切にして支援しているのかが薄くなります。今回のkajiiのレビューでは、計測の整備、施策の優先順位付け、結果の記録は説明できている一方で、「顧客が求める価値と、自社の強みをどう結び付けるか」が弱いと指摘されました。

専門家の資料を、文章の評価にも使う

そこで、分析や施策の説明に、顧客の期待と自社の強みから訴求を考える視点を補いました。さらに、施策の狙い・変更内容・結果・判断理由を記録し、次の分析でAIにも参照させる流れを明確にしています。文章を整えるだけでなく、元の資料にあった考え方がページから抜け落ちていないかを確かめるレビューになりました。

ここでも、これまでのセミナー資料が役に立ちました。資料をサイトの文章に使い直すだけでなく、その文章を評価するためにも使える。専門家という役割名に加えて、自社の人が説明してきた内容を渡すことで、レビューの指摘も具体的になります。コンテンツの二次利用は、書く材料を増やすだけではないのだと感じました。

振り返り：AIでのWeb制作でうまくいった進め方と改善点

今回は「Astra、かなりできそうだ。試してみよう」というノリで始めたところがあります。その勢いがあったから、短期間でここまで試せました。一方で、作る対象が広がるにつれて、先に整理しておけばよかったことも見えてきました。

うまくいったこと

まず、既存ページを残して別案を作り、実物を見ながら注文できたことです。頭の中だけで完成形を考えるより、「ここはよい」「これは違う」と具体的に伝えられました。AIの速さを、案を比較して考えるために使えたと思います。

会社にあった資料を使えたことも大きかったです。セミナー資料を読んでデータ基盤の図を描き直したり、HubSpotの受注データからメンバーの経験業種を整理したりしました。蓄積した情報が、私たちの仕事を具体的に伝える材料になりました。

また、私だけで判断せず、岩永や別のAI、分野ごとの専門役にも見てもらいました。文章、動き、情報の配置、使いやすさと、見る観点を変えることで、自分が気づかなかった問題を拾えました。ここでいう「うまくいった」は制作の進め方についてで、集客や問い合わせへの効果は、これから見ていくことです。

本当は、こう進めるべきだった

トップで手応えを得た段階で、記事、サービス詳細、申し込みフォーム、サンクスページまで確認すべきでした。PCとスマホで代表的なページと操作を確かめてから広げれば、似た修正の繰り返しを減らせたと思います。

共通部品についても、作った時点で、その部品をどのページに使うかまで整理しておくべきでした。今回は部品ができていても、ページ側には古いものや保存済みの設定が残り、確認し直す場面がありました。

SEO、IA・UX、ユーザビリティ、アクセシビリティの確認も、最初の案ができた段階から制作に組み込みたいところです。後半に集中して点検するより、ページを増やす前に一度、公開前にもう一度、専門役に見てもらう。そのタイミングを先に決めておけばよかったと思います。

そして、「修正した」「本番に反映した」「公開ページで動作を確認した」を、最初から分けて管理すべきでした。途中からLinearやスプレッドシートで整理しましたが、何をもって完了にするかが曖昧だと、人もAIも同じ場所を確認し直すことになります。

次回は、目的と材料、確認の仕方を先に揃えてから始めます。

制作前に揃える目的・材料・確認項目

次に同じような制作をするなら、最初に次の5つを短くまとめて渡したいです。

• 目的と優先順位：誰に何を伝え、どの行動につなげたいか。今回はどのページまで作り、何を後に回すか。
• 現状と残すもの：ページと導線の一覧、現在の表示や計測状況、ロゴや大切なコピー、既存のフォーム・通知設定。比較できるよう、改修前の状態も残しておく。
• AIが参照する材料：セミナー・提案・サービス紹介資料、公開記事、CRMデータの所在。どれが最新版で、どこまで公開に使えるかを添える。
• 作業範囲と役割：テスト環境と本番環境、AIが操作できる範囲、公開を判断する人、文章やデザインを確認する人を決める。
• 確認項目と完了条件：PC・スマホの表示、リンク、フォーム送信後の動作、計測、SEO、WCAG 2.2を基準にしたアクセシビリティの確認を、誰がいつ行うか決める。

この準備があれば、まず作ってみる勢いを保ちながら、出てきた案を判断しやすくなります。細かい見た目や文章は、引き続き実物を見ながら詰める。目的と材料、確認の仕方を先に共有しておくのが、今回を踏まえて次に変えたいところです。

この実験でわかったこと：速さを支えたのは、判断と蓄積だった

今回やってみて、最初に抱いた「AIと画面を見ながら進めれば、自社サイトを変えられるのでは」という期待には、手応えがありました。まず全体をぶわっと作り、実物を見てフィードバックし、細かなところを直す。最初から詳細な要件定義を完成させるというより、作りながら必要なことが見えてくる進め方でした。ただ、判断の基準まで不要になったわけではありません。誰に何を伝えるページかが曖昧だと、AIの案に何を注文すればよいかも決まりません。

Xにも書きましたが、いまは「なんか微妙」の原因を見立て、どの専門役に何を考えてもらうかを決めるところに、制作の経験やセンスが出ます。ただ、工程ごとに呼ぶ専門役やレビューの観点まで型化されたら、この部分も変わっていくのでしょう。私自身はWeb制作者ではありませんが、今回の制作で、その変化を身近に感じました。

「AIでWebサイト制作、ヤバいのでは」について、実際に自社サイトを作ってみて感じたこと。
今のところ、どんなサブエージェントを召喚するかに、Web制作者の経験やセンスが出る。
今回も、IA Consultant、Art Director、Motion Designer、Accessibility Reviewer、Editor、HubSpot…

— 西 正広 / (株)月曜日のトラ (@macchaice) 2026年9月12日

CMSの更新作業までAIに任せる

CMS操作こそ、AIのBrowser Use（ブラウザ操作）が得意とするところだとも感じています。管理画面を開いて、文章や画像を入れ、設定を確かめ、表示を見て直す。HubSpotのモジュールを活かし、その後に人が更新できる形まで扱えたことで、AIに任せられる範囲の広さを実感しました。

セミナー資料が、自社らしい説明の材料になる

そこでオリジナリティの材料になるのが、会社がこれまで蓄積してきた情報です。セミナー資料、提案資料、サービス紹介資料には、私たちが何を課題と捉え、どう説明し、何を支援してきたかが残っています。必要な情報を検索し、その内容を参照して文章などを生成するRAG（検索拡張生成）の考え方を、サイト制作にも持ち込む。今回、資料を読んでもらってサービスの説明や図を直したのも、その発想です。

月曜日のトラは、これまで継続してセミナーを開催してきました。その分、AIに渡せる材料がたくさんありました。データ基盤の図を描き直せたのも、私たち自身が説明してきた資料があったからです。セミナーのために作ったコンテンツを、今度はサイトの文章や図として活かす。提案資料やサービス紹介資料にも、同じように再利用できる知見があります。

コンテンツの二次利用がカギになる。AIが作る速さを活かすためにも、日々の仕事や発信で蓄積したものを、もう一度使える状態にしておく。その積み重ねが、自分たちらしいサイトを作る力になると感じました。

公開後の細部にも、時間とトークンを使った

そして意外だったのは、全体を形にすること以上に、細部を詰めるところで時間もトークンも使う感覚があったことです。トップの印象は数日で大きく変わりました。でも、その後に残るのは、見出しの折り返し、メニューの間隔、関連記事カードの重複、スマホで触ったときの違和感といった、一つひとつは小さなことです。一つ直したら、別のページでも確かめる。そこでまた、次の違和感が見えてきます。

日別の集計でも、公開翌日の9月11日から14日までで全体の約47%を使い、最多は公開後の9月11日でした。この期間にはコンテンツの拡充や調査、記事編集も含まれるので、すべてが細部の修正というわけではありません。人の作業時間も厳密には計っていません。それでも、形ができたらあとは少し直すだけ、とはいかないことはよくわかりました。

神は細部に宿るとは、よく言ったものです。AIが大きな形を速く作ってくれるほど、人が気にする小さな違和感がはっきり見える。出来上がった瞬間の驚きと、日々使うときの心地よさは、少し違うものなのだと思います。その間を埋めるための往復に、今回もずいぶん時間を使いました。

AIでのWeb制作におけるトークン使用量と、生産性の見方

2026年9月7日17:00から14日21:24まで、サイト制作の親タスクと20のサブエージェントで使った量は、約20.52億トークンでした。執筆と並行して進めた、9月14日21:24までの改修も含みます。ただし、別タスクのkajiiや、Claude Code、Réti、画像生成などは含まない集計です。

大きな数字ですが、入力の約97.64%は、以前に処理した内容を再利用するキャッシュ分です。出来上がった文章やコードの量ではなく、会話や資料を繰り返し扱った処理量と捉えてください。

比較用に非キャッシュ入力・キャッシュ入力・出力をGPT-6 AstraのAPI単価に当てはめ、1ドル150円で換算すると約40.5万円相当でした。実際の支払額ではありません。私自身は、サブスクと「おかわり」の追加枠があって助かりました。案を見て、注文し、また直してもらう。その往復を続けられたことは大きかったです。

使える状態にするまでの速さで、生産性を考える

では、生産性はどうだったか。今回は「目的に合う変更を、表示や動作を確認して、使える状態にするまでの速さ」で考えています。最初の公開まで4日、まずまず納得するまで8日。実物を早く見られることで、次の判断へ進みやすくなりました。

一方、人が使った実作業時間は記録しきれていないので、「生産性が何倍になった」とは言えません。次回は、依頼から確認完了までの時間、人が対応した時間、やり直しの回数も残したいです。生成の速さに加えて、確認や手戻りを含めてどれだけ進められたかを見たいと思います。

詳しい内訳・換算条件・専門役の一覧は、記事末尾の補足にまとめました。

制作会社とのWeb制作とAI主導のWeb制作の費用比較

今回の改修を制作会社に依頼するとしたら、どのくらいの案件になるのでしょうか。HubSpotでのサイト構築やコーポレートサイト制作を手がける4社の公開情報を調べ、料金だけでなく、テンプレートの活用、資料ダウンロードや複数サービスへの対応、デザイン・実装の範囲、制作期間を見比べました。

その公開情報をもとに、既存のHubSpot基盤とコンテンツを活用する今回の条件に当てはめると、150〜250万円程度（税別）、中心は200万円前後、制作期間は2〜3カ月という概算になりました。2026年9月14日時点の公開情報を参考にAstraが算出した目安で、制作会社から今回のサイトについて見積もりを取得した金額ではありません。

今回は見た目の変更に加え、共通部品、サービス説明、記事の表示、SEOやスマホでの調整も扱っています。小規模な基本プランの価格や各社の料金を単純に平均するのではなく、こうした対応範囲を踏まえて見積もっています。

概算に含む範囲と、含まない費用

既存記事を一つずつ新規制作するのではなく、主要ページと共通テンプレートを改修し、手元の資料や原稿を使う前提です。独自デザインや動きの作り込み、CRMデータを使った原稿整理、修正回数によっては、この幅を超える可能性があります。新規取材・撮影、全ページの個別改稿、WCAG 2.2の全面的な適合検証、保守やHubSpot利用料は含めていません。公開料金から実作業時間まではわからないため、人日数は断定せず、確認待ちを含む制作期間で比較しています。

この概算と約40.5万円のAPI参考換算を引き算して、そのまま節約額にはできません。私自身が判断し、フィードバックした時間もありますし、公開後の検証も続きます。それでも、情報設計からCMS実装、文章、SEOまでを短期間に行き来できたことは、今回の実験で感じた大きな変化でした。

AIのスピード感に合わせたWeb制作の在り方とは

今回のスピードを考えるうえで、ひとつ外せない前提があります。自分で自社サイトを作ることと、クライアントのサイトを作ることは、やはり違います。

今回は、決定権を持つ私自身が画面を見て、「ここはこうして」「やっぱり前のほうがいい」と、その場でAIに頼めました。岩永との確認はありましたが、変更のたびに何人もの承認を待つ必要はありません。AIが作る速さに、こちらの判断も合わせやすい環境だったわけです。

これがクライアントワークだったらどうでしょう。あるいは、同じ会社でもシステム部門と事業部のやりとりだったら。「一度持ち帰って確認します」「修正版は来週の定例で見ましょう」という流れは、AIを使っただけでは変わりません。修正そのものが10分で終わっても、確認が翌週なら、そこで一週間待つことになります。

もちろん、調査や制作が速くなる効果はあると思います。ただ、従来の確認サイクルのまま、今回と同じスピード感を再現できるとは思いません。AIが作業を速くするほど、人や組織が判断するまでの時間が、全体の進み方を左右するようになります。

組織の中で、実装と判断を近づける

その確認待ちを減らす方法として、顧客の組織に入り込み、事業の背景を理解しながら実装まで進める、FDE（Forward Deployed Engineer）のような役割が有効だと考えています。要望を持ち帰って作るだけでなく、何を実現したいのかを一緒に考え、その場で形にして判断を促す役割です。

ただ、その人を置けば済むわけでもありません。どこまで現場で決めてよいのか、誰の確認が必要なのか、いつ確認するのか。そこまで揃っていなければ、組織の中に入っても、結局は同じ承認待ちになります。

改善を繰り返す進め方に、契約も合わせる

私は、仕事の契約も、こうした進め方に合わせて変わっていくと思います。最初に仕様と完成物を決め、それを納める請負よりも、一定の期間、専門家として一緒に改善を進める準委任が合う場面は増えると思います。実際、IPAのアジャイル開発モデル契約も準委任を前提に、発注側が適時に意思決定する役割を整理しています。

もちろん、すべての制作が準委任になるという話ではありません。ただ、実物を見て考えが変わり、作っては確かめ、必要なら作り直す。その繰り返しを前提にするなら、変更を例外として扱う契約では進めにくくなります。

今回も、案や見せ方は何度も作り直しました。一方で、HubSpotにあるコンテンツやフォーム、計測、更新の仕組みは活かしています。試した案を捨てられることと、事業の土台まで壊してよいことは別です。

AIを使えば制作は速くなる。でも、その速さを仕事全体の速さに変えるには、人の関わり方や決め方、契約まで考える必要がある。自分のサイトを自分で作ってみたからこそ、次にクライアントワークで何を変えるべきかも、少し見えた気がします。

自社サイトをAIでリニューアルした経験から学んだこと

今回、何より大きかったのは、「自分にも、ここまでできる」という実感を持てたことです。私はWeb制作者ではありません。それでも、今あるサイトと会社の資料を渡し、出てきたものを見て注文を重ねることで、実際に使うサイトを変えられました。AIならできるらしい、と聞いているときと、自分のサイトが目の前で変わっていくのを見るのとでは、受け止め方がまるで違いました。

その実感は、次に何かを考えるときの前提を変えます。これまでは依頼の仕方や必要な手間を考えて止まっていたことも、まず一度、形にして確かめてみようと思える。今回得たのは、改修されたサイトと、そうやって試せる範囲が自分の中で広がったことでした。

便利さだけでは収まらない、恐れと畏敬

ただ、うれしいだけではありません。CMSの仕組みを扱い、会社の資料を読み、専門役に意見を求め、こちらが別のことをしている間にも作業が進んでいる。ここまでできてしまうものを前にすると、恐れも感じます。便利な道具を一つ覚えた、という感覚には収まりません。自分が想像していた仕事の進め方が、足元から変わっていくような、畏敬の念に近いものがありました。

今は、どこが気になるかを見立て、誰に何を考えてもらうかを決めるところに、経験が活きています。会社が蓄積してきた資料も、私たちらしい内容を作る力になりました。ただ、その役割分担がこの先も同じとは限りません。今回できたことに驚いたからこそ、いまのAIの得意・不得意だけで、これからを決めつけないでおきたいと思います。

自分にもできる、という手応えと、ここまでできてしまうのか、という恐れ。その両方が残った8日間でした。だから、これからも実際に使い、作ったものを自分の目で確かめていきたい。8日間の区切りを迎えた後もサイトを直しているのは、まだよくできるところが見えるし、もう少し先まで試してみたいからです。

9月28日（月）12:00–12:30｜無料オンライン・ランチタイムセミナー

ここまで読んでくださり、ありがとうございます。このリニューアルの経験をみなさんにもお伝えしたく、9月28日（月）12:00–12:30に、無料のオンライン・ランチタイムセミナーを開催します。

当日は、GPT-6 Astraがブラウザを操作するBrowser Useのデモも行います。ご質問も歓迎です。ご参加を希望される方は、以下のフォームからお申し込みください。

Appendix：AIでのWebリニューアルのトークンの内訳