僕は日頃かなりAIを使っています。
ちょっとした質疑応答はもちろん、資料の取りまとめ、情報や要点の整理、自分用のツールの作成、バックオフィス業務の自動化などなど、仕事のいろいろな場面で助けてもらっています。
本当に便利。
一方で、Web制作のプロジェクトをある程度まとまった単位で任せられたことは、実は今のところほとんどありません。
調査や文章整理、要件の洗い出しなど、工程の一部をお願いすることはかなり増えました。ただ、プロジェクトの背景を理解してもらい、サイト構造を考え、ワイヤーフレームを作り、CMSや運用まで含めて設計を一貫して進めてもらうとなるとまだまだかなりの難しさを感じます。
単純に僕のプロンプトが悪い可能性も大いにありそうですが。
で、特に最近考えているのが、Web制作の前半戦にある「情報設計」とAIの相性でございまして。
AIの進化は速いので、しばらくしたら僕は全然違うことを言っているかもしれませんが、現時点でWebサイトの情報設計にAIをどう使うとよさそうか、実務を通して感じていることを整理してみます。
※なお、この記事ではサイトマップ、ディレクトリマップ、ワイヤーフレーム、仕様書、要件定義書などなど、Webサイト制作の初期段階で行う設計業務を広めに「情報設計」と呼んでいます。ご容赦を。
結論：AIは成果物を作れても、情報設計を丸ごと任せるのはまだ難しいっぽい
結論です。
少なくとも弊社では、現時点（2026年8月時点）でWebサイトの情報設計をAIに丸ごと任せるのは難しいかもと感じています。
サイトの概要や必要そうなページを伝えれば、それっぽいサイトマップやワイヤーフレームはかなり速く作ってくれますし、シンプルなサイトであればそのまま叩き台として使えることも確かにあります。
が、実務では「サイトマップができた！」「WFができた！」で設計が終わるわけではなかったりします。
僕がAIに情報設計を丸ごと任せるのはまだ難しいと感じるのは「AIがサイトマップやWFを作れない」ということではなく、「裏側にある設計判断をプロジェクト全体で一貫させた上で設計するにはまだ課題がある」と思っているからです。
「それっぽい成果物」と「成立している設計」はだいぶ違う
AIに情報設計資料一式を作ってもらったりすると、必要そうなページは一通り揃っていることがあります。
ある程度なら「それっぽさ」もバッチリ。
ただ、よく見ると分類軸が混ざっていたり、変なテキスト入っていたり、似た役割のページが別々の階層に置かれていたり、意味の全くわからないセクションがあったり、実際には用意できないコンテンツが混ざっていたり、CMSでは管理しにくい構造になっていたり、別ページと役割が重複していたりすることがあります。
挙げ始めたらキリがないですねえ。
一見するとそれっぽい感じで成立している様に見えるんですが、「このページに来たユーザーは何を知りたいのか」「どの情報を理解した時点で次の行動に移れるのか」など考えると、要素が並んでいるだけで、情報の順序に理由がないことがあります。
Webサイトでは「必要そうな要素が揃っていること」と、「ユーザーの理解や行動に合わせて情報が設計されていること」は別物です。
同時に「最初のアウトプットが速いこと」と「プロジェクト全体が速く進むこと」も別ですね。
生成速度は速いが、手戻りが発生すると結局時間が無駄に
前提が整理されていない状態でAIにワイヤーフレームを作らせると、必要そうな要素をかなりの勢いで補ってくれます。
AIの成果物が厄介なのは、なまじ見た目がそれっぽく成立してしまうことですね。
そのまま進めてしまい、デザインフェーズに入ってから「この設計、そもそもどういう想定なんだ…？」となっては後の祭りです。
ワイヤーフレームやサイトマップの見直しはもちろん、そもそもこのプロジェクトってなんだっけという場所まで遡ってしまうことになりかねません。
さらに怖いのは、その設計ですでにお客様の承認を取ってしまっている場合。
あとから「やっぱり構成を変えます！」となれば「え、マジすか。なんで？」となってしまいますし、単に社内調整をいただくだけでは済まないかもしれません。
改めて変更理由を説明することは当然として、場合によっては再承認を取る必要があ流かもしれません。当然、納期にも影響しますし、お客様にも制作側にも余計な確認や工数が発生します。
よくない。
最初に数時間楽をするためにAIへ考えることまで任せた結果、後工程でその何倍もの手戻りを生んでしまっては意味がありません。
まさに急がば回れ。
前工程で考えることをサボると、その判断のツケをデザインや実装、さらにはお客様にまで回すことになるかもしれません。
AIを使うときほど、ここは気をつけた方がいいよねと思っています。
「プロジェクト固有の文脈を設計に変換すること」はまだ人の仕事っぽい
Webサイトの情報設計では「一般論として正しいか」も大事ですが、「そのプロジェクトにとって何が正しいか」も慎重に判断する必要があります。
AIに資料を大量に渡せば、項目を列挙すること自体はできますが「この案件ではどの条件を重く見るべきか」「ユーザーの負担と運用側の負担をどこでバランスさせるか」「仕様書に書かれていないが、実務上ここが危なそうだぞ」と判断するには、そのプロジェクトの経緯や関係者の状況まである程度理解する必要があります。
これがAIにはまだできません。
僕がAIに情報設計を丸ごと任せにくいと感じる大きな理由の一つはこれです。
Webサイトの設計には、Webサイトの中には書かれていない情報がかなり影響してきます。
その文脈を読み取り、曖昧な要望や制約条件を具体的な設計判断へ変換することは、今のところ人が担うべき部分がまだ大きいと思っています。
お客様ごとの「背景」はAIには分からない
情報設計では、仕様書や要件だけを読んで作ればいいというわけにはいきません。
弊社では大変光栄なことに官公庁関連のWebサイト制作をお手伝いする機会を多くいただくのですが、特に官公庁案件では、民間企業とは違う作法や確認の流れが求められることも多く、同じWebサイト制作でも考え方はかなり変わります。
お客様ごとの慣習や意思決定の仕方、担当者間の役割分担、その組織ならではの進め方まで想像しながら設計する必要があります。
もちろん僕らもそのすべてを完璧に理解できているとは思っていません。ただ、打ち合わせやこれまでのやり取りから、その組織では何を重く見るのか、どこで慎重になるべきなのかは、可能な限り考えながら設計しようとしているつもりです。
こうしたプロジェクト固有の「しぐさ」は、当然ながらAIには分かりません。
「こんなプロジェクトだよ」とゴリゴリに作り込んだプロジェクトチャーターを渡せば情報はある程度理解してくれるとは思いますが、その組織では何を重く見るのか、どこで慎重になるべきなのかまで含めて設計へ落とすには、実際に関係者とやり取りしている人の理解が重要だと思っています。
プロジェクトの仕様や背景を理解しないと情報設計はできない
特に官公庁案件は顕著かもしれませんが、仕様書や各種ガイドラインは情報設計にかなり影響します。
仕様書に全ての技術的な要件が記載されているわけではないので、事業内容を理解したり、類似の事業の共通項などを探ったり、書面に記載された条件が設計のどこへ影響するのかを翻訳したりする必要があったりします。
仕様書をAIにいきなり入れると色々まずい部分もあるので、ここは人の仕事ですね。
たとえば「アクセシビリティは適合レベルAAに準拠してね」と仕様書に書いてあった場合、「デザインが完成してから色や文字サイズだけを確認すればいいよね！」とというわけにはいきません。アクセシビリティは情報設計や画面構成、操作方法などにも関わるため、設計の初期段階から要件として組み込んでおく必要があるためです。
また、既存コンテンツを大量に移行する案件であれば、現在のサイトマップだけを見て新しい構造を作るのもかなり危険ですね。
旧URLをどう引き継ぐのか、削除するページをどう扱うのか、PDFをどうするのか、リダイレクトをどう設計するのかまで含めると、ディレクトリ設計やCMSの構造にも影響しますし。
この辺りはまだまだAIがカバーしきれないところだと思います。
Webサイトの外側にある業務まで見ないと、UIは決められない
もう一つ大きいのが、サイトの外側にある業務ですね。お客様の組織体制なども関わってくる部分です。
たとえば相談フォーム。
相談フォームはユーザーが送信できればUIとしては成立します。が、相談フォームの受け取り手のことも考慮しなくてはいけません。
- 誰が内容を確認するのか
- 入力内容をメールで受け取るだけでいいのか
- 管理画面に蓄積するべきか。そもそもしていいのか
- 個人情報を誰がどこまで保持するのか
- 対応後のステータスをどう管理するのか
などなど、パッと思いつくだけでもこれぐらいはありますよね。これらによって、フォームで取得すべき項目や入力形式も変わります。
このように画面上のUXだけではなく、その前後にある業務まで含めて設計する必要があります。「問い合わせフォームのUIを作ってね」と指示すればそれっぽいものは出てきます。
が、それが実際使用できるかはまた別の話。
AIを情報設計に使用する際の心がけは「アウトプットの密度は高く、お客様の認知負荷は低く」がいいっぽい
情報設計にAIを使うとき、まず大きな仮説は自分で考えるようにしています。
プロジェクトの目的やユーザー像、サイト全体の構造、どんな導線をつくるべきかとか。こうした上流の判断まで最初からAIに任せるのではなく、まず自分なりの仮説をつくることが大事。
そのうえでAIと壁打ちをして、仮説の精度を上げていく使い方が今のところ一番しっくりきています。
AIの力が役立つのは、ある程度方向性が決まったあとの細かな検証的な部分だと思うんです。
例えばこんなことを聞いたりします。
- このプロジェクトの前提で考えたとき、この導線設計は本当に適切か
- 各ページの役割や掲載内容に重複・抜けはないか
- 情報の優先順位はこれでいいか
- このページに情報を詰め込みすぎていないか
- 別のページへ分けたほうが理解しやすくならないか
などなど「基本の部分がしっかりできているかどうか」に関しては重箱の隅をつつくくらい細かくディスカッションしてもらうといい感じ。そこで出てきた指摘をもとに、また自分で考えます。
これを繰り返していくと、最初に立てた仮説が少しずつ強固になっていくんですね。
このとき意識しているのが「アウトプットの密度は高く、お客様の認知負荷は低く」ということ。
こちら側ではかなり細かいところまで考え、できるだけガッチガチに検証します。もちろん可変する可能性も想定した余白も持って。
でも、それをお渡しするとお客様の認知負荷がすごいので、表に出すときには「ここはこんな感じになるのかな」「構成なのはこんな理由からなんだな」をできるだけ迷わず理解できる状態まで整理することが大事だと思っていますし、そのための整理作業を大切にしたいと考えています。
流れとしてはこんな感じ。
- まず考える（人）
- AIに細部を徹底的に検証、議論してもらう（人&AI）
- それを元にアウトプットの密度を高くする（人&AI）
- 2と3を繰り返す（人&AI）
- お客様に分かりやすい形に整える（人）
AIに情報設計そのものを任せるというより、自分の考えに何度も突っ込みを入れてもらい、最終的な成果物の密度を上げていくという使い方がかなり効果的な気がしています。
まとめると：「AIに情報設計を任せる」のではなく「情報設計のプロセスにAIを組み込む」のが大事っぽい
ここまで整理してみると、現時点では「AIに情報設計を任せる」という考え方そのものが、少し違うのかもしれません。
AIは、見栄えのいいサイトマップやワイヤーフレームをかなり速く作れるようになっています。一方で、実際の仕事には、単純な生成では置き換えにくい判断がまだかなり残っています。今のところは、人とAIの仕事をきれいに切り分けるというより、情報設計のプロセスそのものにAIを組み込むほうが自然だと思っています。
今後さらにAIが進化すれば、サイトマップやワイヤーフレームだけでなく、デザインやCMS設計や実装までかなりの部分が自動化されるのかもしれませんね。
そうなると、Web制作の仕事で価値が残るのは「成果物を速く作れること」ではなく、その前にある「設計」と「判断」なのではないかと思うんです。
むしろ、AIによって制作そのものが速くなるほど、その前段で何を設計するのかを決める力の重要性は高くなる気がしています。
ここはかなり人の仕事ですね。
- 何を作るのか。何を作らないのか
- 誰に、何を、どの順番で伝えるのか
- どの情報を、どの単位で管理するのか
- 意図をデザインにどう反映するのか
- この配置は人にとって便利な配置なのか
- お客様にはいつ、何を、どのような形でお渡しするのか
- どこまでをシステムで解決し、どこからを運用で補うのか
など。
こうした判断が曖昧なままでは、AIがどれだけ高精度な成果物を作れるようになっても良いWebサイトにはならないと思います。
制作会社としては、それっぽい成果物を生成して、それを納品するだけで対価をいただくわけにはいきません。僕らが担うべきなのは、その成果物に至るまでの判断を引き受けることであるはずなので。
少なくとも現時点では、AIを情報設計者の代わりにするのではなく、情報設計者の思考を拡張し、判断の精度を上げる相手として使うのがいいのかもしれませんね。
僕には、そのくらいの距離感が一番しっくりきています。