第7回（最終回）：1人でAIチームを組む — ハーネス設計で業務ルーティンをエージェント化した全工程
シリーズ: コードなしで仕事が変わる AIエージェント設計ガイド（全7回・最終回）
第1回は「ChatGPTもClaudeも使っているのに、仕事が楽にならない」という話から始まりました。あれから6回、毎回一歩ずつ設計を積み上げてきた。最終回のこの記事では、その全部がつながる場所に辿り着きます。
第1回で出てきた、AIを「チャット相手」から「業務を任せる存在」に変えるという発想。第2回のClaude Projectsで「分身」を育てる方法。第3回のGeminiとGoogle Workspaceを組み合わせた日常業務の自動化。第4回で学んだCLAUDE.mdへの業務言語化。第5回のIT承認なしでできる現場の効率化。そして第6回のMCPによるツール接続。
これらは独立した技術ではありませんでした。1人がAIチームを運営するための設計思想が、順番に積み上がっていたのです。
この最終回では、Worply Mediaの全体構成を包み隠さず公開します。5つのロールが連携して1つのメディアを動かす仕組みを、設計の考え方ごと伝えます。
「1人AIチーム」とはどういう状態か
「AIチーム」という言葉を聞いて、SFっぽいと感じた方もいるかもしれません。実態はもっと地味です。
1人AIチームとは、複数の役割をAIに持たせて、それぞれが連携する設計を作ることです。その核心は、役割を「機能」として定義することです。「賢いAIに何でも聞く」のではなく、「企画専用のAI」「執筆専用のAI」「分析専用のAI」を別々に育て、それぞれの出力が次の入力になる流れを設計する。
これは人間のチームと同じ構造です。優秀な1人のスーパーマンに全部任せるより、得意分野に特化した役割分担がある方が、品質と速度の両方が上がります。
ただし、大きな違いが一つあります。人間のチームは意思疎通のコストが高い。AIチームは、設計さえ正しければ、伝達コストがほぼゼロです。CLAUDE.mdに書いたルールは全員が完全に理解し、MCPで共有されたデータは全員がアクセスできる。
これが「1人でAIチームを組む」ことの本質的なメリットです。
Worply Mediaの全体構成を公開する
このメディアがどういう仕組みで動いているか、初めてここで全部話します。
5ロール体制の設計
Worply Mediaは5つのロールで運営されています。
planner（企画・戦略） コンテンツ方針の決定、タスク管理、優先度付けを担います。Linearのチケットを確認し、Notionのコンテンツ方針と照らし合わせながら「今週何を作るか」を決める。人間でいえば編集長です。
writer（執筆） 企画をもとに記事のドラフトを書きます。リサーチ結果を受け取り、CLAUDE.mdで定義されたトーン&マナーに従って文章を書く。このシリーズを書いているのもwriterロールです。
editor（校正） writerが書いたドラフトをレビューします。事実確認、文体チェック、SEO観点のレビューを行い、「公開可」か「要修正」かを判断します。
designer（画像生成） 記事のアイキャッチ画像とグラレコ（グラフィックレコーディング）を生成します。Gemini MCPを使い、決められたフラットデザインスタイルで画像を作ります。
analyst（データ分析） GA4とSearch Consoleのデータを分析し、どの記事が読まれているか、どのキーワードで検索されているかを可視化します。plannerの意思決定に使われる月次レポートを作ります。
これら5つのロールはそれぞれ独立したCLAUDE.mdを持っています。editor用のCLAUDE.mdにはeditorとして振る舞うためのルールが書かれていて、writerを呼び出せばwriterのルールが適用される。役割を呼び出すたびに、そのロールの「業務マニュアル」が読み込まれます。
補足しておくと、CLAUDE.mdはClaude Codeという開発者向けCLIツールで使われる設定ファイルです。読者の皆さんがこれを再現するには、Claude Projectsで役割ごとに独立したプロジェクトを作り、それぞれの「プロジェクトの指示（Custom Instructions）」に同じ内容を書き込む方法が最も簡単です。著者はCLAUDE.mdファイルで管理していますが、Claude Projectsの指示欄に同じことを書けば、機能的には同じ効果が得られます。
CLAUDE.mdの設計（第4回の実践例）
各ロールのCLAUDE.mdには、共通して4つの要素が含まれています。ここではWorply Mediaの実例として紹介しますが、Claude Projectsを使う場合は「プロジェクトの指示」にこの内容を書き込んでください。
## このロールの責務
（何をするロールか、一言で）
## 操作対象
（何を作ったり編集したりできるか）
## 判断基準
（どう判断するか、例外の扱いは）
## 禁止事項
（絶対にやらないこと）
第4回で「業務の言語化」として学んだことが、ここで具体的な形になっています。特に「禁止事項」セクションが重要で、たとえばwriterのCLAUDE.mdには「editorの校正前に記事を公開すること」という禁止事項があります。このようなガードレールがないと、AIは良かれと思って予期せぬ行動を取ることがあります。
MCP接続先の設計（第6回の実践例）
各ロールが使えるツールも、ロールごとに定義されています。
- planner: Linear（タスク管理）、Notion（コンテンツ方針）
- writer: GitHub（記事ファイルの編集）、Notion（編集方針の参照）
- editor: GitHub（記事の校正）、Notion（NGワード・表記ルール）
- designer: Gemini MCP（画像生成）
- analyst: GA4、Search Console（データ取得）
接続先が多ければいいわけではありません。アナリストがタスク管理ツールを見る必要はないし、デザイナーが記事ファイルを書き換える権限は不要です。「このロールは何にアクセスできるべきか」を設計するのも、ハーネスエンジニアリングの一部です。
記事1本ができる流れを追う
実際に記事1本が完成するまで、どういうフローで動いているかを説明します。
1. planner がテーマを決める LinearのMediaチームに積み上がっているタスクを確認し、Notionのコンテンツ方針と照らし合わせながら「今日書く記事」を選びます。この判断は今でも人間（自分）がやっています。AIに完全に任せると、優先順位の微妙なニュアンスが失われることを経験から学んだからです。
2. writer が下書きを作る テーマと、必要であれば参考情報を渡してwriterを呼び出します。writerは自分のCLAUDE.mdを読み込んで、定められたトーン&マナーに従って記事を書きます。このシリーズのような「です・ます調」か、ニュース記事の「だ・である調」かも、CLAUDE.mdで定義されています。
3. editor がレビューする writerの出力をeditorに渡します。editorはチェックリストに基づいて校正を行い、「公開可」か「要修正」かをレポートします。ファクトチェックも含む本格的なレビューです。過去に自分がeditorのレビューをスキップしたとき、数字の誤りを見落として公開してしまったことがあります。今はeditorのチェックを必ず通すフローにしています。
4. designer が画像を生成する 記事の内容をdesignerに渡し、アイキャッチ画像とグラレコを生成します。Gemini MCPを使い、フラットデザインという統一スタイルで作ります。このスタイル定義もCLAUDE.mdに書いてあります。「毎回違うデザインにならないこと」という制約が、メディアとしての一貫性を生みます。
5. デプロイして完了 GitHubにpushすると、Cloudflare Pagesが自動でデプロイします。このステップはコードを書く必要はなく、ファイルを所定のフォルダに置いてコミットするだけです。
このフローを最初に構築するのに要した時間は、おそらく丸2日程度でした。ルールを書いて、試して、壊れた部分を直して、また試す。それが今では毎日動いています。
非エンジニアがこれを再現するための4ステップ
「Worply Mediaの仕組みは理解したけど、自分には難しそう」という方のために、再現可能な手順を整理します。いきなり5ロールを目指す必要はありません。
Step 1: まず2ロールから始める
「リサーチ役」と「ドラフト役」の2つだけ作ってみてください。
- リサーチ役: 「このテーマについて調べて、箇条書きでまとめて。参考になりそうなURL付きで」
- ドラフト役: 「このリサーチ結果をもとに、〇〇向けの提案書の骨格を作って」
この2ロールがあるだけで、「ゼロから自分で調べて自分で書く」より大幅に速くなります。完璧なシステムを目指さなくていい。まず2つで回してみることが大切です。
Step 2: Claude Projectsで各ロールを分離する
第2回で学んだClaude Projectsを使います。リサーチ役プロジェクトとドラフト役プロジェクトを別々に作り、それぞれのプロジェクト設定に役割の指示を書き込みます。
プロジェクトが分かれることで、「リサーチに来たらリサーチモード」「ドラフト作業に来たらドラフトモード」という切り替えが自動になります。毎回「あなたはリサーチ担当です」と言わなくて済む状態が、生産性の体感を大きく変えます。
Step 3: MCPで外部ツールを繋ぐ
第6回で学んだMCPの接続です。まずは1つだけ繋いでみてください。NotionかGoogle Driveが始めやすいです。
繋いだ後、「Notionのこのページを読んで、提案書に使えそうな情報を抽出して」と頼んでみてください。コピー&ペーストが不要になったとき、AIが「ツールを使える状態」になったことが実感できます。
Step 4: ワークフローを文書化する
2ロールが安定して動くようになったら、その運用ルールをテキストで書いておきます。「リサーチ役はこういう形式でアウトプットする」「ドラフト役はそれを受け取ってこう使う」という取り決めです。
これがCLAUDE.mdの発想です。ルールが頭の中にあるうちは属人的で、文書化された瞬間にシステムになります。文書化することで、AIが「毎回説明しなくても動く」状態になり、さらに自分が「どこを改善すれば全体がよくなるか」を俯瞰できるようになります。
なお、Claude Projectsを使う場合はこのルール文書をプロジェクトの「プロジェクトの指示」欄に貼り付けるだけです。CLAUDE.mdという特別なファイルを用意する必要はありません。書く内容は同じで、置き場所が違うだけです。
ハーネス設計の本質
ここまで「AIに手綱をつける」という表現を使ってきましたが、最後に少し違う視点で整理したいと思います。
ハーネス設計の本質は「AIを制御する」ことではなく、AIが活躍できる場を設計することです。
馬術の世界では、優れた騎手は馬の能力を最大限に引き出すために手綱を使います。馬を抑え込むためではなく、馬が最も力を発揮できる状態に導くために。AIハーネスも同じで、CLAUDE.mdに書くルールは「こう動け」という命令より「この環境でなら最高のアウトプットが出る」という文脈の提供に近い。
Worply Mediaを運営してきて気づいたのは、AIが「自分の仕事を理解している」と感じるほど、アウトプットの質が自然に上がるということです。プロンプトを精緻化するより、文脈を整える方が効果的でした。
失敗から学んだこと
正直に話します。最初はうまくいきませんでした。
立ち上げ当初は、全部自動化しようとしました。ニュース記事のリサーチからデプロイまで、人間の介入をゼロにする設計を目指した。結果は見事に失敗でした。
何が起きたかというと、AIが「正しいと判断したこと」と「自分が意図していたこと」がずれていくのに気づかないまま、おかしな記事が量産されていきました。事実確認の漏れ、トーンのブレ、SEOキーワードの無理な詰め込み。どれも個別のチェックをスキップした結果です。
今の設計には、必ず人間が判断する場所が残っています。「今週何を書くか」の決定、「この記事を公開していいか」の最終判断、「この方針でいいか」の定期レビュー。これらはAIに任せていません。
「人間が判断し、AIが実行する」——この構造が安定した運営の根幹です。完全自動化を目指すより、人間の判断コストを下げる方向で設計した方が、結果的にクオリティも速度も上がりました。
これからの展望
ここからは少し先の話をします。
AIエージェントは今、「道具」から「チームメイト」への移行点にいます。道具は使う人間が操作する。チームメイトは文脈を共有して、一緒に仕事を考える。
現在のAIエージェントはまだ完全にチームメイトではありません。文脈を持続させる能力、予期せぬ状況への対応力、長期的な判断の一貫性——これらはまだ人間が補う必要があります。でも、その差は急速に縮まっています。
1年前の自分に今の運営を見せたら、驚くと思います。1人でメディアを運営しながら、AIチームが記事の大半を下書きし、校正し、画像を生成している。それが今の現実です。
この先の展望は、AIチームがより文脈を共有できるようになり、人間の介入が必要な場面がさらに絞られていくことだと思っています。そのとき、ハーネス設計を学んでいる人と学んでいない人で、仕事の生産性に大きな差が出るでしょう。
このシリーズが、その準備のきっかけになれば嬉しいです。
シリーズ全体を振り返る
7回を振り返ると、一本の道が見えてきます。
第1回では、問題の核心を整理しました。AIを「チャット相手」から「業務を担う存在」に変えるには、設計が必要だということ。
第2回と第3回では、その設計の最初の一歩として、「分身を作る」方法を学びました。Claude ProjectsとGeminiでAIに自分の仕事を教える。毎回ゼロから説明しない状態を作る。
第4回では、分身の質を高める方法を学びました。CLAUDE.mdへの業務言語化。ルールを文書化することで、AIが「あなたの仕事を知っている状態」になる。
第5回では、IT承認の壁を超える方法を学びました。会社データがなくてもできる業務効率化は、実は思ったより広い。
第6回では、AIとツールを繋ぐ方法を学びました。MCPによってAIが「閉じた会話」から「あなたのツール群にアクセスできる状態」に変わる。
そしてこの第7回では、それらを統合する「1人AIチーム」の設計思想と全工程を共有しました。
最後の一記事一アクション
シリーズを通して「一記事一アクション」という形式で続けてきました。最終回も同じです。
自分の仕事で、まず2つの役割をAIに持たせてみてください。
リサーチ役とドラフト役でも、情報収集役と要約役でも、データ分析役とレポート役でも何でもいい。2つのロールを定義して、それぞれにClaude Projectsで別々のプロジェクトを作る。そこに「このロールはこういう仕事をする」という指示を書き込む。
それだけが最初のステップです。5ロールは後からついてきます。
第1回で「AIを業務に組み込む設計が足りない」と言いました。この記事まで読んだあなたには、その設計の全体像が見えているはずです。あとは自分の仕事に置き換えて、動かしてみるだけです。
7回お付き合いいただき、ありがとうございました。
シリーズ全7回
- 第1回：ChatGPTもClaudeも使っているのに、仕事が楽にならない理由
- 第2回：Claude Projectsで「仕事の分身」を作る
- 第3回：Gemini × Google Workspaceで毎日の業務をAIに任せる
- 第4回：業務を言語化する力がAIの精度を決める — CLAUDE.mdライティング入門
- 第5回：IT部門を通さずにAIを使い倒す — 会社データなしでできる業務効率化
- 第6回：MCPって結局何？コードを書かずにClaudeをNotionとSlackに繋いだ3ステップ
- 第7回（最終回）：1人でAIチームを組む — ハーネス設計で業務ルーティンをエージェント化した全工程（この記事）
関連記事
- 第6回：MCPって結局何？コードを書かずにClaudeをNotionとSlackに繋いだ3ステップ
- Claude Code サブエージェントで5ロール体制を組む実践ガイド
- 148件突破、awesome-claude-codeが示すClaudeエコシステムの輪郭