前回は、このサイトをAI協働で作ることにした理由をお話ししました。
今回は、プロジェクトの出発点——「AIエージェントとの役割分担をどう設計したか」について書きます。
実はこれ、AI協働プロジェクトで一番大事な部分かもしれません。
いきなりAIに「作って」と言ってはいけない理由
AIに「ポートフォリオサイト作って」とお願いしたら、何かしらのものは出てきます。でも、たいていは「なんか違う……」となります。
これ、人間のチームでも同じですよね。新しいメンバーに「このプロジェクトよろしく」と丸投げしたら、うまくいくはずがない。
まず「誰が、何を、どこまで担当するか」を決める。当たり前のことですが、AI相手でもこれは変わりません。むしろ、AIは自分で判断して動けない分、より丁寧な設計が必要です。
最初にやったこと——全体像のスケッチ
プロジェクトを始めるにあたって、まず僕がやったのは全体像の整理でした。
- サイトの目的: ポートフォリオ＋技術ブログ＋お問い合わせ導線
- 必要なページ: トップ、Works（実績）、ブログ、お問い合わせ
- サイトのトーン: ダークテーマで、落ち着いた雰囲気。でも堅すぎない
- ざっくりスケジュール: 数週間で公開まで持っていきたい
この「方向性を決める」という仕事は、人間がやるべき部分です。
なぜかというと、AIは「要求に応える」のは得意ですが、「そもそも何を作るべきか？」を考えるのは苦手だからです。料理に例えるなら、AIは腕の良いシェフ。でも「今日のメニューは何にする？」はオーナー（人間）が決めないといけません。
AIを「PM」に任命する——このプロジェクトの肝
このプロジェクトで一番大きな決断は、AIエージェントを「PM（プロジェクトマネージャー）」に任命したことです。
普通のAI活用って、「人間がAIに指示を出して、結果を受け取る」というイメージですよね。でも、このプロジェクトでは違うアプローチを取りました。
僕は「顧客」のような立場で要望を伝える。PMであるAIエージェントがその要望を受け取って、自分の判断でプロジェクトを回す。
使ったのは、Claude Codeの「Agent Teams」という機能。複数のAIエージェントをチームとして同時に動かせる仕組みで、それぞれが独立したセッションを持ちつつ、メッセージのやりとりや共有タスクリストを通じて協調して作業を進められます。
具体的な体制はこうです——
- 僕（人間）——「こういうサイトにしたい」と要望を伝える。いわば顧客の立場
- PMエージェント——プロジェクトを管理する司令塔。僕の要望を受けて、タスクの分解・チーム編成・作業の割り振りを自分の判断で行う
- 実装担当エージェント——PMの指示を受けて、コンポーネントやAPI処理をコーディング
- 確認担当エージェント——実装されたコードのレビュー、品質チェック
一人開発なのに、登場人物が4者いるんです。
「人間（顧客）→ PM → 実装/確認チーム」——実際の開発現場に近い階層構造。
たとえば僕が「Worksページを作りたい」と伝えると、PMがそれを「データ構造の設計」「API作成」「UIコンポーネント」「レスポンシブ対応」……と分解して、チームメンバーに振り分けてくれる。実装が終われば確認担当がレビューして、問題があればPM経由でフィードバックが返ってくる。僕はPMからの報告を見て、最終判断をするだけ。
これ、普通に顧客としてWeb制作会社に依頼するのとほぼ同じ流れなんですよね。違うのは、チームメンバーが全員AIだということだけ。
なぜPMをAIに任せたのか
「自分でPMをやればいいのでは？」と思うかもしれません。でも、あえてAIに任せた理由があります。
一人開発の弱点は、「作る人」と「管理する人」が同一人物になってしまうこと。コードを書いていると、つい目の前の実装に没頭して、全体の進捗や優先順位を見失いがちです。
PMをAIに任せることで、僕は「何を作りたいか」「これでいいか」という判断に集中できました。タスクの分解やチームの割り振りは、PMが回してくれる。この分業が、想像以上にうまく機能したんです。
各メンバーの役割
改めて、それぞれの担当範囲をまとめます。
人間（僕）——顧客であり、最終決裁者
- 方向性の決定——何を作るか、何を優先するか
- 品質の最終判断——「これでOK」と言うか「やり直し」と言うか
- ユーザーの気持ちを想像する——「サイトを見た人はどう感じるだろう？」
- 自分だけの知識——フリーランスとしてのリアルな経験や事情
PMエージェント——プロジェクトの司令塔
- プロジェクト管理——タスクの分解・優先順位づけ・進捗管理
- チーム編成——タスクの内容に応じて、適切なメンバーを割り振る
- 認識合わせ——僕の意図をチームメンバーに正確に伝える
- 調査・提案——技術選定やアーキテクチャの選択肢を出す
実装/確認エージェント——手を動かすメンバー
- コードを書く——コンポーネントやAPI処理の実装
- コードレビュー——書いたコードを別の視点でチェック
- ドキュメント作成——設計書や型定義などの文書化
- デバッグ——エラーの原因調査、修正案の提示
ひとことで言えば、「要望は人間、管理はPM、実行はチーム」。僕がいちいち細かい指示を出さなくても、PMが判断してチームを動かしてくれる。これが基本ラインです。
フェーズごとにチーム編成が変わる
ここが面白いところなんですが、「実装担当＋確認担当」はあくまで基本構成。PMはフェーズの内容に合わせて、チーム編成を柔軟に変えていました。
たとえば——
企画フェーズでは、コードを書く人は不要。代わりに「サイト構成を考える人」「コンテンツ戦略を練る人」「技術候補を調査する人」の3名体制。サイトの方向性を固めることに集中したチームです。
設計フェーズでは、「デザイン方針を決める人（カラー・タイポグラフィ・コンポーネント設計）」と「技術アーキテクチャを設計する人（ディレクトリ構成・API設計・キャッシュ戦略）」の2名体制。作る前の「設計図」を固めるチーム。
実装フェーズでは、さらに分業して「フロントエンド担当」「WordPress API担当」「アニメーション担当」「ページ統合担当」の4名体制。それぞれが専門領域に集中できるようにしていました。
テスト・品質チェックフェーズでは、「ビルド検証」「コード品質チェック」「ユニットテスト」「コンポーネントテスト」と、観点別に4名体制。
そして公開後のUI改善では、「デザイン調査担当」「実装担当」「レビュー担当」の小規模チームを都度立ち上げて対応——といった具合です。
チーム編成を固定せず、フェーズに合った専門チームを組む。
これはPMの判断で行われていて、僕が「次は〇〇担当を入れて」と細かく指示したわけではありません。タスクの性質を見て、PMが最適な編成を考えてくれる。ここにPMを任せた価値が出ていると感じました。
タスクの分解——AIに頼みやすいサイズにする
役割分担が決まったら、次は「やること」をリストアップして分解します。
たとえば「Worksページ（実績紹介）を作る」というタスク。これをそのままAIに投げると、ぼんやりしたものが返ってきます。そこで、こんな風に分解しました。
- WordPressのデータ構造を設計する → AIに設計案を作ってもらう
- データの入力項目を決める → 設計案を見て、僕が判断する
- サーバー側のAPI（データ取得処理）を作る → AIにコードを書いてもらう
- カード型のUI部品を作る → AIにコードを書いてもらう
- フィルタリング（絞り込み）機能 → AIにコードを書いてもらい、使い勝手は僕が調整
- スマホ対応とアクセシビリティ → AIと一緒にチェック
ポイントは、各タスクが「AIに頼みやすいサイズ」になっていること。大きすぎると焦点がぼやけるし、小さすぎると効率が悪い。ちょうどいい粒度にするのが、人間の腕の見せどころです。
指示の出し方で、結果が大きく変わる
AI協働で一番大事だなと感じたのが、「指示の出し方」です。
ちょっと比べてみてください。
ふわっとした指示:
「いい感じのカードコンポーネント作って」
具体的な指示:
「Works用のカードコンポーネントを作って。表示項目はプロジェクト名・サムネイル画像・技術タグ・概要文。ダークテーマ対応、スマホでも見やすいレイアウトで。色やサイズは既存のCSS変数（–color-accent, –space-4など）を使って」
後者のほうが、圧倒的に良い結果が返ってきます。
これは「AIの性能が低いから」ではなく、「何を作りたいかを明確にする」こと自体が、良いものを作るための第一歩だからです。人間のデザイナーやエンジニアに依頼するときも、同じですよね。
プロジェクトの「地図」を共有する
Claude CodeにはCLAUDE.mdというファイルを通じて、プロジェクトの情報をAIに共有できる仕組みがあります。ここに、こんなことを書いておきました。
- プロジェクトの全体構成
- 使っている技術
- フォルダ構造
- デザインの方針
- 設計ドキュメントへのリンク
イメージとしては、「新しく入ったチームメンバーに渡すオンボーディング資料」に近いです。これがあるとAIが迷わず作業できるようになるので、出力の質がぐっと上がります。
うまくいかなかった場面も、正直に
もちろん、全部スムーズだったわけではありません。
たとえば、「ページ遷移のアニメーションを作って」とお願いしたとき。技術的には動くものが出てきたんですが、実際にブラウザで見ると「うーん、なんか違うな……」と。
AIは言われた通りのものを作るのは上手です。でも、「これを見た人はどう感じるか？」「本当に使いやすいか？」という判断は、やっぱり人間がしないといけない。
この話は第5回（デザイン・演出編）で詳しくお話しします。
まとめ——「PM任命」で開発の景色が変わる
このプロジェクトの肝は、AIを単なるコード生成ツールとして使うのではなく、PMとして任命してプロジェクト全体を任せたこと。
そうすることで、僕は——
- タスクの分解や割り振りを自分でやらなくていい
- 「何を作りたいか」と「これでいいか」の判断に集中できる
- チームメンバー間の調整もPMが回してくれる
- 結果を確認して、必要なら方向を修正すればいい
つまり、顧客のような立場で、AIチームにプロジェクトを進めてもらうという体制。人間のチームに仕事を依頼するのとほぼ同じ感覚です。
この体制をうまく機能させるために大事なのは、「全体像を描くこと」と「要望を言葉にすること」。逆に言えば、それさえできればAI PMが動いてくれる。マネジメントの経験がある人ほど、AI協働はうまくいくと思います。
次回は、技術選定のお話です。「NuxtとNext.js、どっちにする？」「CMSはどうする？」——そんな判断をAIとどう進めたかをご紹介します。