人間と複数のAIで、Webプロジェクトを実行してみた

PHASE 01｜リニューアル要件定義 — ChatGPT

最初に取り組んだのは、公式サイトのリニューアルで何を実現するのかを決める作業です。

ChatGPTには要件定義の担当者として、目的、課題、対象顧客、提供価値、品質要件、成功条件を検討させました。協議では、現在の事業価値を重視するのか、将来目指す事業像を優先するのかについて、AIの提案が揺れる場面がありました。実験者がその矛盾を指摘し、現在提供できる能力を根拠にしながら、将来の可能性も示す方針を決定しました。最終的に、事業価値を正しく伝えて新規顧客の相談・受注につなげることを目的とし、8項目の要件を確定しました。

PHASE 02｜既存サイト調査・分析

次の専門家には、PHASE 01の要件定義書と既存公式サイトを渡し現状調査を依頼しました。調査対象は、サイトマップに掲載された258 URLと、追加で発見した20 URLの計278 URLとしました。うち275 URLでHTTP 200を確認し、ページ構成、トップページの情報、要件との差を記録しました。しかし、初期のリンク抽出には、CSSや画像など、ページの遷移先ではないものが混在していました。実験者は抽出結果の誤りを指摘し、一覧を手作業で修正するのではなく、抽出プログラム自体を修正して再実行するよう求めました。修正後は、保存済みデータに対して同じ抽出結果が得られることも確認しています。

この工程で得られたのは、新しいサイトの設計案ではありません。後工程が検討するための、既存サイトに関する事実と課題です。

PHASE 03｜情報設計・コンテンツ設計 — ChatGPT

PHASE 03では、要件定義と現状調査の結果を受け取り、サイト全体の情報構造とトップページの掲載内容を設計しました。特に議論が集中したのは、会社が提供する能力を、利用者にどのように見せるかという問題です。AIはカテゴリの分類や掲載内容を繰り返し提案しましたが、実際の提供能力との関係が曖昧なものや、必要以上に営業色の強い構成もありました。実験者は各提案を確認し、主力サービスの分類、コンテンツの優先順位、詳細ページへの導線、トップページに問い合わせCTAを設けない方針を決定しました。

成果物では、トップページを「メインビジュアル→事業案内→できること→Web改善ラボ→お知らせ」の5セクションとし、「できること」には4つのカテゴリを配置しました。

原稿の一部や新設ページのURLは未確定のまま、後工程へ申し送っています。

PHASE 04｜HTMLワイヤーフレーム制作 — Codex

ここから、文書による設計を実際の画面へ変換する工程に入りました。Codexには、情報設計資料と独自制作基盤「K2 Project Base（新しいタブで開きます）」を渡し、HTMLにてワイヤーフレームを制作させました（HTMLワイヤーフレーム）。初回の制作では、画面構成を概ね再現できたものの、K2pbの仕様に準拠しない独自のCSSやJavaScriptが追加されていました。

最大の問題は、K2pbの仕様に基づいて制作・保守を行う担当者が、生成されたコードを円滑に引き継ぎ、更新できなくなることです。そこで実験者は、既存のコンポーネントと実装規則を使用し、独立した検証環境で再制作するよう指示しました。

再制作したver2では、K2pbの既存コンポーネントやスタイル、JavaScriptを優先して使用する構成へ改善しました。ビルド対象Sassの既存ソースとの一致率は99.25％。これはソース行の一致率であり、部品の利用率を示すものではありません。K2pbの仕様に沿った実装へ近づいたことで、既存の制作ルールに基づく保守・更新への引き継ぎが容易になると考えられます。

成果は、K2pbの資産を利用したHTMLワイヤーフレームを制作できたことです。 一方、イレギュラーな操作をした際の動作など、一部の課題は残りました。

PHASE 05｜ビジュアルデザイン要件定義 — ChatGPT

HTMLワイヤーフレームをFigmaへ渡す前に、別の専門家としてChatGPTにビジュアルデザインの要件を定義させました。デザインコンセプトは、「知性・品位・先進性。静かだが、意思が強い。」 です。配色、文字、図版、余白、レイアウト、アクセシビリティといった8項目について、実験者とAIが協議しました。この工程では、見た目の印象を表す抽象的な言葉に加えて、K2pbのタイポグラフィやレイアウト仕様を参照するよう実験者が求めています。また、HTMLワイヤーフレームは情報構造の基準とする一方、デザイナーが合理的な理由に基づいて視覚表現を提案できるようにしました。

PHASE 06｜ビジュアルデザイン制作 — Figma AI

PHASE 04で制作したHTMLワイヤーフレームをFigmaへ取り込み、PHASE 05で定義したデザイン要件に基づいて、Figma AIによるビジュアルデザイン制作を行いました。

まず、HTMLからFigmaへの取り込み方法を検証しました。「Design Capture」では取り込みに成功したものの、編集上の制約がありました。「Capture code」でも取り込みはできましたが、編集が困難だったため採用を見送りました。また、「Extract designs」でも取り込みに成功しましたが、K2pbのCSSクラスを引き継ぐことはできませんでした。最終的に、今回の実験ではDesign Captureを正式な取り込み方法として採用しました。

続いてFigma AIにデザイン制作を依頼しました。しかし、初回の生成結果はワイヤーフレームの配置や余白を踏襲したもので、期待したビジュアルデザインには至りませんでした。

そこで実験者は制作条件を変更しました。原稿や情報構造は維持しながら、既存フレームの配置・幅・カード構造には拘束されず、独立したデザイン案を制作するよう指示しました。この変更によって視覚表現の自由度が高まり、当初のワイヤーフレームから発展したデザイン案が生成されました。

さらに実験者は、メインビジュアルの優先順位、4つの提供領域の独立性、事業案内図の表現、タイポグラフィについて修正を指示しました。制作過程では、AIが制作上の説明文をページ本文へ混入させる問題も発生しました。また、K2pbの仕様を参照できても、Figma上で既存コンポーネントやCSSクラスが自動的に継承されるわけではないことも確認しました。

最終的なデザインの完成度について、実験者は暫定的に約4割と評価しました。これは実験者による主観的な評価です。

今回確認できたのは、Figma AIによってビジュアルデザインの初期案を制作できることです。 実務で求める完成度に到達するには、人間のデザイナーによる仕上げが必要という結果になりました。

PHASE 07｜FigmaからHTMLへの再実装 — Codex

続いて、Figmaで制作したデザインをHTMLへ反映する実験を行いました。今回は、FigmaのデザインをCodexが直接参照する方法（A方式）と、Figma Makeが生成したコードをCodexが利用する方法（B方式）の2つを検証しました。どちらも、K2pbの既存資産と実装仕様を活用し、人間の担当者が保守・更新を引き継げるコードを生成することが共通の目標です。

A方式｜Figmaデザインを直接参照

Codexがオンライン上のFigmaデザインデータとPHASE 04のHTMLを直接参照して実装しました。K2pbの共通SassやJavaScript、ヘッダー、記事一覧などの既存部品を活用し、比較的簡潔なHTMLを生成できました。既存の制作ルールに沿った構造であり、保守・更新のしやすさに利点がありました。一方、事業案内の図版は画像として切り出され、文字や接続関係を直接編集できなくなりました。また、デザインが一部省略されているなどの抜け落ちがありました。

B方式｜Figma Makeの生成コードを利用

Figma Makeが生成したReactコードをCodexに渡し、静的HTMLへの変換を試みました。初回の実装では、見た目の再現性は高かったものの、Make独自のコードが多く残り、K2pbの既存部品を十分に活用できていませんでした。これでは、K2pbの仕様に基づいて作業する担当者が、既存の制作ルールに従って更新することが難しくなります。そこで実験者は、Figma Makeが生成したReactコードをCodexで静的HTMLへ変換し、K2pbの既存コンポーネントを使用して再実装するよう指示しました。再実装後は、共通のカード、ナビゲーション、一覧などの構造を活用する形へ改善されました。Figma Makeの描画結果との画素差は、1440px幅で0.82％、375px幅で0.68％と報告されています。ただし、これはMakeの描画結果を基準とした数値であり、Figma最終デザインとの一致率ではありません。

この工程では、デザインの再現性に加え、既存の制作基盤に準拠した実装と、その後の保守・更新のしやすさを評価する必要があることが明らかになりました。

PHASE 08｜独立した品質検証 — ChatGPT Work

PHASE 07で制作した2つのHTMLについて、実装担当の自己評価とは別に品質検証を実施しました。検証では、K2pbの仕様への準拠性、デザインの再現性、コード品質、アクセシビリティ、実装効率、拡張性の6項目を対象としました。特に重視したのは、既存のクラス名やファイルを使用しているだけでなく、K2pbのコンポーネントやスタイルが実際に機能しているかという点です。

コードの構造、Sass、JavaScriptに加え、ブラウザーで実際に適用されるCSSやキーボード操作を確認しました。その結果、A方式では、CSSに記述されたレイアウト指定がK2pb既存の設定と競合し、意図した指定が適用されていない箇所が発見されました。B方式の再実装版では、既存コンポーネントの活用が進んだ一方、独自の上書き指定が多く、リンクのように見えても操作できない要素が残っていました。

両方式とも、8種類の画面幅で横方向のはみ出しや画像欠落、検出対象としたJavaScriptエラーは確認されず、基本的なキーボード操作も成立しました。比較評価では、今回の成果物に限り、B方式の再実装版がK2pbの既存部品の活用と保存デザインへの再現性で優位とされました。

一方、A方式はHTMLが比較的簡潔で、共通のSassやJavaScriptを活用しており、保守・更新のしやすさに利点がありました。ただし、人間の担当者への実際の引き継ぎ作業は検証していません。

今回の実験では、制作条件や修正回数が異なるため、実装方式そのものの優劣や工数削減効果は確定できません。また、スクリーンリーダーによる読み上げ、文字拡大、実機での動作、Figmaの最終デザインとの完全一致については未検証です。

今回確認できたのは、AIが生成したコードについても、既存の制作仕様に沿った実装と実際の動作を独立して検証することで、見た目だけでは分からない問題を発見できることです。

PHASE 09｜実験総括 — ChatGPT

最後に、各PHASE の成果物、作業記録、品質検証結果をChatGPTへ渡し実験全体を振り返りました。総括の途中では資料が不足していたため、ChatGPTが不足箇所を指摘し、実験者がPHASE 04・07の詳細記録を追加しました。総括では、各AIの自己申告と、PHASE 08で独立して確認した結果を区別しました。また、制作時間、費用、既存資産の利用状況についても、それぞれの測定範囲を明記しています。結論は、K2pbを中心とした制作工程の一部について実用性を確認できた一方、すべての工程の連携や、別案件で同じ品質を再現できることまでは検証できていないというものでした。

なお、今回の実験は工程を順に進める形で実施しました。後工程から要件定義や情報設計へ差し戻した際、関連する成果物をどのように更新し、整合性を維持するかについては、今後の検証課題として残っています。

得られた成果

複数のAIによる工程分担が機能した

各工程に担当AIを割り当て、Markdown形式の資料を使って成果物と指示を引き継ぐことで、一連の制作を進められました。

既存の制作基盤を活用したHTML実装が可能だった

CodexはK2pbの既存資産を利用してHTMLを生成できました。ただし、初回から仕様に準拠できた工程と、人間による指摘・再実装が必要だった工程がありました。

デザイン制作からHTMLへの変換を複数の方法で検証できた

Figma AIでビジュアルデザインを制作し、Codexによる直接参照と、Figma MakeのReactコードを利用する2つの実装方法を比較しました。いずれも成果物を生成できましたが、デザインの再現性と保守・更新のしやすさには違いがありました。

独立した品質検証によって問題を発見できた

画面表示だけでは分からないCSSの競合や、操作できないリンク表現を発見しました。生成した担当AIの報告だけに依存せず、別工程で実際の動作を検証する有効性を確認しました。

残された課題

AIへの指示だけでは制作仕様の遵守を保証できない

K2pbの仕様を渡しても、独自CSSやJavaScriptが生成される場面がありました。既存部品の使用状況を確認し、必要に応じて再実装を指示する必要がありました。

Figma AIによるデザインの完成度

ビジュアルデザインは初期案の制作まで進みましたが、実験者が求める完成度には達しませんでした。最終的な仕上げは未実施です。

工程間の情報継承と実験記録

Markdownによる引き継ぎは機能した一方、実験の総括時には一部の工程記録が不足していました。また、AIの記録だけでは実験者の意図や修正の経緯を十分に再現できない場面もありました。

実務での効果は未検証

実際の担当者への引き継ぎ、顧客の負担軽減、工数や費用の削減、別案件での再現性については検証していません。

クライアントのフィードバックへの対応

今回の実験は各工程を順番に進めましたが、実務ではクライアントの要望や修正指示によって、前の工程や、要件定義や情報設計まで戻る場合があります。その際、変更内容を関連する工程と成果物へ反映し、品質を維持しながら再実装できるかは未検証です。

総合結果

今回の実験では、人間が各工程の成果を確認し、必要に応じて修正・差し戻しを行うことで、複数のAIによる制作工程を連携させられることを確認しました。一方、成果物の品質と制作基盤への準拠を保つには、人間による専門的な判断と、工程ごとの品質検証が引き続き重要です。

3つのAIに共通する評価

3つのAIはいずれも、人間と複数のAIが役割を分担する制作フローは妥当であり、今回の実験で一定の実現可能性が確認されたと評価しました。また、既存の制作基盤を活用した実装や、独立した品質検証を評価する一方、デザインの完成度や工程間の連携、実務での再現性には課題が残るという認識も共通していました。

各AIの評価と相違点

第三者評価から見えた課題

評価の強弱には違いがありましたが、次の課題が指摘されました。

• 事業コンセプトやブランド定義が、最終成果物まで反映されているかを検証する仕組み
• Figma AIによるビジュアルデザインの品質向上
• FigmaとK2pb間のコンポーネントや実装仕様の継承
• 別案件でも同等の成果が得られるかという再現性
• 人間の作業時間、制作費用、顧客負担の定量的な検証

評価の位置づけ

今回の第三者評価は、実験記録と提供資料を基にAIが行った分析・見解です。3つのAIが共通して評価したこと自体が、制作フローの有効性や事業的競争力を客観的に証明するものではありません。実験で確認できた事実と、各AIによる評価を区別したうえで、今後の制作基盤の改善に活用します。