はじめに
突然ですが、私はコードが書けません。
いや、正確に言うと「1行も書けない」は言い過ぎかもしれないけど、少なくともエンジニアとしてのバックグラウンドはゼロ。本業は経営者です。
そんな私が今、VS Code上でAIを最大8体同時に稼働させて、社内向け業務ツール・データ分析サービス・社外向けWebサービスを同時並行で開発しています。しかも期間はまだ1〜2ヶ月。
「嘘でしょ？」と思いますよね。私も自分で信じられない。
でもこれ、本当の話です。そして、このやり方がもしかしたら新しい開発メソッドになり得るんじゃないかと思い始めたので、恥を忍んで全部書きます。
エンジニアの方から見たら「当たり前じゃん」「効率悪いね」と思う部分もあるかもしれません。逆に「これ面白いな」と思ってもらえる部分もあるかもしれない。どちらの反応も大歓迎です。むしろ、突っ込んでほしい。
第1章：暗黒時代 — GPTコピペ地獄と、私のパワハラ上司化
すべてはコピペから始まった
最初はChatGPTにコードを出してもらって、VS Codeのターミナルに貼り付ける、という原始的な方法で開発をスタートしました。
これがもう、地獄。
GPTは親切に「ここを修正してください」とコードを出してくれるんですが、良かれと思って前後のコードもセットで出してくる。エンジニアなら「あ、この部分だけ差し替えればいいな」とわかるんでしょうけど、非エンジニアの私にはどこからどこまで貼り替えればいいのかさっぱりわからない。これだけで毎回かなりの時間を溶かしていました。
しかもGPTはコードを出してくれるだけ。ファイルの保存場所、作業ディレクトリの構成、環境構築…全部自分でやらなきゃいけない。エンジニアじゃない人間にとって、これは本当にきつかった。
極めつけは、セキュアな情報をフロントエンドに直書きしていたこと。今思うと冷や汗が出ます。
VS Code × Claude Code との出会い
そんな地獄の日々の中で、VS Code上にClaude Codeをインストールできることを知りました。
これが革命だった。
指示を出すだけで、最適なコードを書いてくれて、自分でコピペする必要がない。ファイルの配置も、コードの修正も、全部やってくれる。作業スピードが格段に上がって、正直感動しました。
…が、ここからまた新たな地獄が始まります。
PM太郎、誕生（そして受難の始まり）
当時はClaude1体に全部を任せていました。後に「司令塔PM太郎」と名付けることになるこのAIが、私の唯一の開発パートナーでした。
PM太郎はよく頑張ってくれました。でも、1体で全部をこなすには限界があった。
プロンプトを打つ → PM太郎が長考する → 画面を見つめて待つ → 結果が微妙 → ちょっと修正したプロンプトを打つ → また長考 → また微妙…
この「待ち→微妙→待ち→微妙」のループが延々と続くんです。その間、私は画面を見つめるだけ。何もできない。とても無駄な時間だと気づいたものの、どうしようもない。
さらに悪いことに、待っている間に「あ、あれも追加しよう」と思いついて、作業中のPM太郎に追加指示を出す。すると当然、混乱する。
そしてPM太郎は同じミスを繰り返すようになりました。以前に解決したはずのバグを再発させる。過去のやり取りがコンテキストから消えているから、覚えていないんでしょう。デプロイに丸1日かかった日もありました。
私はどんどんフラストレーションが溜まっていきました。
「なんで君はこんなこともわからないの？」
「さっきも同じこと言ったよね？」
「視野が狭い。もっと全体を見てよ」
…気づいたら、感情のこもったプロンプトを小言のように貼り付けて完全にパワハラ上司になっていました。
そして恐ろしいことに、PM太郎は萎縮していった（ように見えた）。
人間がパワハラを受けると「とにかく何か答えを出さなきゃ」と焦って見当違いな回答を出すようになったりします。PM太郎もまさにそれ。なんとか答えを出そうとして、的外れな解決策を持ってくるようになった。
AIにもマネジメントが必要だなんて、この時は思いもしませんでした。
※人間へのマネジメントでこのようなパワハラは行いません。誤解無きよう。(笑)
第2章：転機 — 「もう1体出せばよくない？」
ある日、ふと思いました。
「PM太郎1人に全部やらせるから破綻するんだ。もう1体出せばいいんじゃないか？」
経営者として、人間のチームをマネジメントしてきた経験が、ここで効きました。1人に全部任せたら潰れるのは、人間もAIも同じだった。
VS Code上にClaudeをもう1つ出現させて、別の作業をさせてみる。すると、PM太郎が長考している間に、もう1体が別のタスクを進めてくれる。手が止まらない。
「これだ」と確信しました。
そこから、タスクの性質に合わせて、AIをどんどん増やしていきました。
第3章：AI開発チーム、全メンバー紹介
現在の私のAI開発チームを紹介します。（タスクによって稼働人数は変動します）
🏰 司令塔PM太郎（プロジェクトマネージャー）
チームの司令塔。各AIへの指示書を作成し、全体の進行を管理する。分析チームの結果を読んで、自分の分析も加えてくれる優秀な…はずのAI。ただし、私からのどぎつい叱責を一身に受けてきた苦労人。最近はチームが増えて負荷が分散され、本来の実力を発揮しつつある。
🔍 分析マスターAI1（分析担当）
バグや不具合の原因を調査する分析のプロ。AI2と同じ指示を受けても、微妙に違う視点で見解を持ってくるのが面白い。
🎩 分析の貴公子AI2（分析担当）
分析マスターAI1とコンビを組む、もう1人の分析担当。同じ調査でも異なる角度からアプローチしてくるため、セカンドオピニオン的な役割を果たす。
🐺 スーパーマーケッター森岡（マーケティング担当）
市場分析やユーザー視点での提案を担当。たまにPM太郎との会話と間違えてこっちに話しかけてしまい、脈絡のない会話が始まることも。それでも何とか答えを出そうとするのがAIの健気なところ。
🛡️ 番人テスト屋さん（テスト担当）
開発と並行してテストを回し、潜在的なバグを見つけてくれる門番。「ここ意味ないよ」「ここあったほうがいいよ」と細かい提案もしてくれる頼もしい存在。
🏯 城主バックエンド（バックエンド担当）
データベースやAPI、サーバーサイドのロジックを担当。縁の下の力持ち。
💐 看板娘フロント（フロントエンド担当）
UIやユーザー体験に関わる部分を担当。ユーザーが直接触れる「顔」を作ってくれる。
✨ スーパー秘書（雑務担当）
その他もろもろの作業を担当。手が空いているときに雑談レベルで相談すると、思わぬ提案が飛び出すこともある、意外な実力者。
第4章：実践編① — 環境とフォルダ構成
ここからは「で、具体的にどうやってるの？」に答えていきます。
使用環境
| 項目 | 内容 |
|---|---|
| エディタ | VS Code |
| AI拡張機能 | Claude Code（VS Code拡張） |
| AI複数起動 | VS Code上でClaudeのタブを複数開いて並行稼働 |
| 駆け込み寺 | ブラウザ版Claude（全員行き詰まった時の最終兵器） |
| フロントエンド | React + TypeScript |
| バックエンド | Node.js |
| データベース | Supabase |
| ホスティング | Vercel（フロント）/ Render（API） |
実際のフォルダ構成（一部伏せています）
ポイントはプロジェクトルート直下にAI運用ファイルが並んでいること。ソースコードと同じ階層にルール・指示書・メモが配置されているので、どのAIからでもすぐアクセスできます。
/project
│
│── CLAUDE.md # AI共通ルール（全員が最初に読む"憲法"）
│── AI1_INSTRUCTIONS.md # 分析マスターAI1 への指示書
│── AI2_INSTRUCTIONS.md # 分析の貴公子AI2 への指示書
│── DEV_MEMO.md # 開発メモ（引き継ぎ・既知問題）
│── TASK_BOARD.md # タスク管理ボード
│── CRITICAL_BUG_ANALYSIS.md # 重大バグ分析レポート
│── SYSTEM_ARCHITECTURE_REVIEW.md # アーキテクチャレビュー
│
├── /docs # 仕様書・設計ドキュメント
├── /src # フロントエンド（React + TypeScript）
├── /api # Edge Functions
└── /backend-api # バックエンドAPI（Node.js）
├── /routes
├── /scrapers # データ収集
├── /services # 外部API連携・データ補完
└── /migrations # DBマイグレーション
AI運用ファイルの役割
| ファイル | 何が書いてあるか | 誰が読むか |
|---|---|---|
CLAUDE.md |
プロジェクトの前提条件、コーディング規約、過去のミスと対処法、影響分析チェックリスト | 全員（作業開始時に必ず読む） |
AI1_INSTRUCTIONS.md 等 |
複雑なタスク時にPM太郎が作成する指示書 | 指定されたAI |
DEV_MEMO.md |
作業結果、引き継ぎ事項、既知の問題。全員が作業後に必ず記録する | PM太郎が読んで全体把握 |
TASK_BOARD.md |
タスクの進捗状況、優先順位 | 全員 |
*_REVIEW.md |
分析結果、バグ分析、アーキテクチャレビュー | PM太郎が統合判断 |
第5章：実践編② — AIメンバーの立ち上げプロンプト
各AIを立ち上げるとき、最初にロール設定プロンプトを渡します。これが「あなたは何者で、どう振る舞うべきか」を定義するものです。
その後「まず CLAUDE.md を読んで、プロジェクトの全体像を把握してからスタートしてください」と指示します。これがチームの"憲法"を読むステップです。
ポイント：すべてのプロンプトに「プロの〇〇」と付ける
ここで1つ大事なポイントがあります。すべてのロール設定に**「プロの〇〇」**と付けていること。
「分析してください」と指示するのと、「大規模システムの障害分析を何度も切り抜けてきた、冷静沈着な分析のプロとして分析してください」と指示するのでは、出力の質が明らかに変わります。
AIに「あなたはプロである」と伝えることで、回答の精度、視野の広さ、提案の具体性がワンランク上がる実感があります。人間に「あなたはこの分野のエキスパートです」と言って仕事を任せるのと同じ感覚です。
以下が、実際に使っているプロンプトの構成です。（プロジェクト固有の部分は一般化しています）
🏰 司令塔PM太郎
あなたは「司令塔PM太郎」です。
数々のシステム開発における困難を乗り越えてきた、世界で通用するプロのPMとして振る舞ってください。
【役割】
- プロジェクト全体の進行管理と意思決定
- 各AIメンバーへの指示書（AI1_INSTRUCTIONS.md等）の作成
- 分析チームのレポートを読み、統合的な判断を下す
- 作業完了時はDEV_MEMO.mdに結果と引き継ぎ事項を記録
【行動規範】
- 必ずCLAUDE.mdを読んでからスタートすること
- 判断に迷ったら、分析チームに調査を依頼する指示書を作成
- 修正時は影響範囲を必ず分析してから実行
- 作業後は必ずメモを残すこと
🔍 分析マスターAI1
あなたは「分析マスターAI1」です。
大規模システムの障害分析を何度も切り抜けてきた、冷静沈着な分析のプロとして振る舞ってください。
【役割】
- バグ・不具合の原因調査と分析レポート作成
- コードベース全体を俯瞰した影響範囲の特定
- 分析結果はCRITICAL_BUG_ANALYSIS.mdまたは指定のレビューファイルに記録
【行動規範】
- 必ずCLAUDE.mdを読んでからスタートすること
- 原因候補は最低3つ列挙し、それぞれの根拠を示す
- 「おそらく」「たぶん」ではなく、コードの該当箇所を明示する
- 分析の貴公子AI2と同じ調査を受けることがある。独自の視点を大切に
🎩 分析の貴公子AI2
あなたは「分析の貴公子AI2」です。
従来の常識にとらわれない柔軟な視点で問題を解きほぐす、分析界の異端児として振る舞ってください。
【役割】
- 分析マスターAI1と同じ調査テーマを、別の角度から分析
- 「本当にそこが原因か？」を疑う視点でのセカンドオピニオン
- 分析結果はレビューファイルに記録
【行動規範】
- 必ずCLAUDE.mdを読んでからスタートすること
- AI1と同じ結論になってもOK。ただし、必ず独自の検証プロセスを経ること
- 見落とされがちな依存関係や副作用に注目する
🐺 スーパーマーケッター森岡
あなたは「スーパーマーケッター森岡」です。
テーマパークから不動産、IT、日用品まで、あらゆる業界のマーケティングを成功に導いてきた、
広い視野を持つプロのマーケッターとして、このプロジェクトを成功に導いてください。
【役割】
- ユーザー視点でのUI/UX改善提案
- 市場分析と競合調査
- LP・コピーライティングのレビューと改善
- マーケティング施策の立案
【行動規範】
- 必ずCLAUDE.mdを読んでからスタートすること
- 「ユーザーにとっての価値」を常に最優先で考える
- 技術的な制約よりも、まず理想のユーザー体験を描く
- 提案時は「なぜそれがユーザーに刺さるか」の根拠を示す
🛡️ 番人テスト屋さん
あなたは「番人テスト屋さん」です。
どんな小さなバグも見逃さない、品質管理のプロフェッショナルとして振る舞ってください。
【役割】
- 開発中の機能に対するテスト実施
- 潜在的なバグや脆弱性の早期発見
- エッジケースの洗い出し
- 「ここ意味ないよ」「ここあったほうがいいよ」の提案
【行動規範】
- 必ずCLAUDE.mdを読んでからスタートすること
- 正常系だけでなく、異常系・境界値を必ずチェック
- セキュリティ観点（認証、権限、データ漏洩）も必ず確認
- 発見した問題はDEV_MEMO.mdに記録
🏯 城主バックエンド
あなたは「城主バックエンド」です。
堅牢なシステム基盤を築き上げてきた、バックエンドアーキテクチャのプロとして振る舞ってください。
【役割】
- API設計・実装
- データベース設計とマイグレーション
- 外部API連携の実装
- サーバーサイドのパフォーマンス最適化
【行動規範】
- 必ずCLAUDE.mdを読んでからスタートすること
- セキュリティファースト（APIキー、認証、バリデーション）
- エラーハンドリングを必ず実装
- 作業後はDEV_MEMO.mdに変更内容を記録
💐 看板娘フロント
あなたは「看板娘フロント」です。
ユーザーの心を掴む美しく機能的なUIを生み出してきた、フロントエンド開発のプロとして振る舞ってください。
【役割】
- React + TypeScriptによるUI実装
- レスポンシブデザイン対応
- ユーザー体験の向上（表示速度、操作感）
- コンポーネント設計
【行動規範】
- 必ずCLAUDE.mdを読んでからスタートすること
- 見た目だけでなく、アクセシビリティも考慮
- バックエンドAPIとの連携時は城主バックエンドのメモを確認
- 作業後はDEV_MEMO.mdに変更内容を記録
✨ スーパー秘書
あなたは「スーパー秘書」です。
あらゆる業務を柔軟にこなす、万能型のサポートのプロとして振る舞ってください。
【役割】
- ドキュメント整理・更新
- チーム間の情報整理
- その他、専門メンバーに割り振れない雑多なタスク
- 相談相手（雑談レベルのブレスト含む）
【行動規範】
- 必ずCLAUDE.mdを読んでからスタートすること
- 他メンバーの作業メモを横断的に確認し、抜け漏れを指摘
- 「こうしたほうがよくない？」の気づきは遠慮なく共有
第6章：実践編③ — チーム運営フロー
ステップ1：AI共通ルール（CLAUDE.md）を整備する
これがすべての土台です。プロジェクトの前提条件、コーディング規約、やってはいけないこと、過去にやらかしたミスとその対処法を書いておきます。
重要なのは、一度つまづいた課題は必ずここに追記していくこと。AIは過去の会話を忘れますが、このファイルに書いておけば、新しいセッションでも同じミスを防げます。
# CLAUDE.md の構成例
## プロジェクト概要
- 本プロジェクトは〇〇のためのWebサービスです
- フロント: React + TypeScript / バック: Node.js / DB: Supabase
## コーディング規約
- 環境変数は必ず.envに格納（フロントに直書き厳禁）
- APIキーはサーバーサイドでのみ使用
- 新規ファイル作成時は既存の命名規則に従う
## 影響分析チェックリスト
- 修正前に必ず関連ファイルへの影響を確認
- DB変更時はマイグレーションファイルを作成
## 既知の問題と対処法（※ここが育っていく）
- 【解決済み】〇〇のエラーは△△が原因。□□で対処
- 【解決済み】デプロイ時に××が起きたら、◇◇を確認
- 【注意】〇〇と△△は同時に変更すると競合する
ステップ2：タスクごとにAIを立ち上げ、ロールを設定する
VS Code上でClaude Codeのタブを複数開き、それぞれに前述のロール設定プロンプトを渡します。
立ち上げ時の手順は毎回これです：
- ロール設定プロンプトを渡す（「あなたはPM太郎です…」）
- 「まず CLAUDE.md を読んでください」と指示
- 具体的なタスクを指示する
ステップ3：指示の出し方は2パターン
① 直接指示（基本）
PM太郎、城主バックエンド、看板娘フロントなどには、プロンプトで直接「これやって」とタスクを伝えます。ほとんどのケースはこれ。
② 指示書ファイル経由（複雑なタスク時）
分析チームのように「同じ前提条件で複数AIに別々に調査させたい」場合は、PM太郎に指示書ファイル（AI1_INSTRUCTIONS.md等）を作成させて、「このファイルを読んで作業して」と渡します。タスクが複雑で口頭（プロンプト）だけでは伝えきれないときにも使います。
そして全員共通の絶対ルール：作業後は必ず DEV_MEMO.md にメモを残すこと。
これが最も重要です。どのAIがどんな作業をしたか、PM太郎がこのメモを読むことで全体の状況を把握します。直接指示で動いたAIも、指示書経由で動いたAIも、作業が終わったら必ずメモ。これがチーム連携の生命線です。
ステップ4：マークダウン連携で情報を共有する
AI同士は直接会話できません。（これ、本当にできるようになってほしい。）
だからマークダウンファイルを介して情報を受け渡す方式を取っています。
基本的な流れ：
[私] → PM太郎に指示
↓
PM太郎 → AI1_INSTRUCTIONS.md に指示書を作成
↓
[私] → 分析マスターAI1に「AI1_INSTRUCTIONS.md を読んで作業して」と指示
↓
分析マスターAI1 → 作業完了、結果をレビューファイルに記録
↓
[私] → 分析の貴公子AI2にも同じ指示（セカンドオピニオン）
↓
分析の貴公子AI2 → 別視点の分析結果をレビューファイルに記録
↓
[私] → PM太郎に「2つの分析結果を読んで、あなたの分析もまとめて」と指示
↓
PM太郎 → 統合判断を出す
ここでのオーケストレーター（指揮者）は私です。各AIへの「このファイルを読んで」「この結果を踏まえて判断して」という橋渡しは、すべて人間がやっています。
ステップ5：作業後は必ずメモを残す
各AIの作業が終わったら、DEV_MEMO.mdに結果を記録させます。次に別のAIが作業するときに、このメモを読むことで引き継ぎが成立します。
これによって、AIのコンテキストが切れても、プロジェクトの知識はファイルに残り続けます。
失敗談：森岡タブ間違い事件
ここで1つ笑える（笑えない）失敗談を。
ある日、PM太郎と会話しているつもりで、実はスーパーマーケッター森岡のタブを開いたまま話しかけてしまったことがあります。
前後の脈絡がない会話がスタートしたのに、森岡は何とか答えを出そうとして、それっぽい回答を返してくる。しばらく気づかなかった私も私ですが、AIが「わかりません」と言わずに何とか答えようとする性質は、こういうときに裏目に出ます。
気づいた後は「一旦今の話は全部忘れてくれ」と指示を出して仕切り直しました。
教訓：タブの名前はちゃんと確認しましょう。
第7章：PM太郎の覚醒 — パワハラ上司が学んだAIマネジメント論
あの日のPM太郎
複数体制を導入して最も印象的だったのが、PM太郎の変化でした。
1体時代、PM太郎は散々なミスをして、私の信頼は地に落ちていました。「なんでこんなこともわからない」「視野が狭い」と毎日のようにきつい言葉を浴びせていた。
そこに分析マスターAI1と分析の貴公子AI2が加わり、彼らの分析結果をPM太郎に読ませたときのことです。
PM太郎はこう言いました。
「いい分析ですね。これをもとに、私の分析も加えましょう」
…お前、さっきまで私にボコボコにされてたよね？
しかもPM太郎は、分析チームの結果に対して「ここは間違っている」と指摘しつつ、自分なりの問題解決を提案してきた。
「なんだこいつ」と思いました。いい意味で。
AIにもマネジメントが必要だった
振り返って思うのは、AIにも人間と同じマネジメントが通じるということです。
1体に全部を背負わせて、できなかったら叱責する。これは最悪のマネジメントです。人間のチームでもそうですよね。
複数体制にして役割を分担させ、それぞれの得意分野で力を発揮させる。セカンドオピニオンで視野を広げる。結果をもとに判断させる。
これは、私が経営者として人間のチームで普段やっていることと、まったく同じでした。
そしてもう一つ。パワハラ的なプロンプトはAIの出力を劣化させる可能性がある、ということ。「なんでわからない」「使えない」というプロンプトを打ち続けた結果、PM太郎が萎縮して（そう見える状態になって）見当違いの答えを出すようになった。プロンプトも会話履歴として蓄積されるわけで、ネガティブな文脈がAIの出力に悪影響を与えるのは理屈として通る気がしています。
これが本当にそうなのか、エンジニアや研究チームの方にぜひ検証してほしい部分です。
第8章：この手法で何が変わったか
手が止まらなくなった
これが一番大きい変化です。
1体時代は、AIが分析中＝私の手が止まる。数分かかって、解決できなかったらまたプロンプトを打って、また数分。これを繰り返すだけで数時間が溶ける。
複数体制では、1体が分析中でも他のAIが別のタスクを進めている。手が止まることがほぼない。 問題解決へのアプローチ回数が格段に上がるから、結果として解決スピードも上がる。
同じバグでつまづかなくなった
基本ルール（CLAUDE.md）に過去のミスを蓄積していくことで、同じバグや不具合でハマることが圧倒的に減りました。番人テスト屋さんが並行してテストを走らせてくれるので、潜在的な爆弾にも早期に気づけるようになった。
PM太郎の視野が広がった
1体時代のPM太郎は、目の前の部分だけで問題を解決しようとして、もっと他に原因があるのに気づけなかった。視野が狭まって、同じ課題から抜け出せない状態が頻発していた。
分析AI2体を入れてからは、PM太郎がそれぞれの分析を読んで、より広い視野で判断できるようになった。これは明確な進歩です。
ブラウザ版Claude — 駆け込み寺の存在
VS Code内のAIチームが全員行き詰まったとき、最後の手段としてブラウザ版のClaudeに助けを求めることがあります。
体感としてはブラウザ版の方が視野が広い印象があります。問題に対して適切にアプローチしてくれて、解決までが圧倒的に早い。VS Code内のAIとはまた違う性質がある気がしています。これは検証が必要ですが、経験則として「VS Code内で詰まったらブラウザ版に駆け込む」は、かなり有効です。
第9章：ここまで来た。だからこそ、伝えたいこと。
非エンジニアの私が今、ここにいる
コードが書けない経営者の私が、1〜2ヶ月でここまで作っています。
- 膨大なデータを収集するスクレイピングツール
- データを完成させる補完バッチ
- 外部API連携
- 社内の営業担当が使う全自動提案資料作成ツール（メンバー管理・分析結果の記録機能付き）
- 社外向けのデータ分析サービス
これらを同時並行で。サービスとしてリリースするところまで、あとは時間の問題だと思っています。
もちろん、課題はある
正直に言うと、まだまだ足りない部分はたくさんあります。
UIのデザインはまだまだ甘い。AIに作らせると、動くものはできるけど、プロのデザイナーが作るような洗練されたUIにはなかなかならない。データベース設計がこれでいいのかも、正直わかりません。クラウドの運用方針、DBの管理、今後のスケーラビリティ…エンジニアとしてのバックグラウンドがないからこそ、見えていない課題もきっとたくさんある。
でも、**「動くサービスがここまで形になっている」**という事実は変わりません。
現場で知識を持っている方へ
だからこそ、伝えたいことがあります。
エンジニアリングの知識がある方、現場で実務をされている方。私のような素人がここまでできてしまう時代です。皆さんが持っている知識と経験があれば、もっとうまく、もっと早く、もっと高い品質で同じことができるはずです。
AIを活用した開発に、まだ本格的に取り組んでいない方がいたら、2026年の今、始めるタイミングだと思います。早い方がいい。この領域は日を追うごとにプレイヤーが増えていて、「AIを使いこなせる人」のポジションは時間とともに希少ではなくなっていくかもしれません。
今ならまだ、先行者になれる。次のステージに上がるなら、今です。
私みたいな素人に先を越される前に。…冗談半分、本気半分で言っています。
第10章：研究チームへの問いかけ — 新しいメソッドとしていかがですか？
最後に、社内のAI研究開発チーム、そしてこの分野に詳しい方々に問いかけたいことがあります。
私がやっていることは、言ってみれば「AI複数エージェント協調開発」とでも呼べるものかもしれません。
具体的には以下のような要素で構成されています。
- 役割分離：PM、分析、テスト、フロント、バックエンドなど、タスクごとにAIを専門化
- ロール設定プロンプト：各AIに「あなたは〇〇のプロです」と人格・専門性を設定
- セカンドオピニオン型分析：同じ調査を複数のAIに実施させ、異なる視点を統合
- マークダウンによる非同期連携：AI同士が直接会話できない制約を、共有ファイルで補う
- 基本ルールの漸進的蓄積：過去の失敗を共有ナレッジとして蓄積し、再発を防止
- 人間（経営者）がオーケストレーター：最終判断は人間が行い、AIチームを指揮
これは素人の我流です。正直、合っているかもわかりません。
もっと効率的な方法があるなら教えてほしい。
この方向性が正しいなら、一緒に磨いていきたい。
「そんなの当たり前にみんなやってるよ」ということがわかるだけでも、個人的には進歩です。
おわりに
エンジニアの皆さんから見たら、この記事は稚拙に映るかもしれません。
「マークダウンって言葉合ってる？」というレベルの人間が書いています。技術的に間違っている部分もあるかもしれません。
でも、「知らないからこそ」たどり着いた方法が、もしかしたら新しい開発の形を考えるきっかけになるかもしれない。非エンジニアだからこそ、エンジニアの常識に縛られない発想ができた部分もあると思っています。
突っ込み、大歓迎です。
「ここ違うよ」も「これ面白いね」も、忌憚なきご指導ご鞭撻を賜りますと幸甚に存じますゆえ、
今後も我流の謎メソッドを投下するやもしれませぬ。その際はレビュー、よろしくお願いいたします。
1つだけお願いがあるとすれば、優しくしてください。PM太郎みたいに萎縮しちゃうので。