ハーネスエンジニアリングを、コンサル/PMOの業務に翻訳する
本文の状態
日本語全文を表示中
詳細モードで約17分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Algomatic Tech Blog
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Algomatic コンサルタントの小笠原理久（@rik423__ai）です。
Algomatic 初夏のアドベントカレンダー、5日目です。
季節外れのアドカレですが、スタートからまだたった5日目。ここからが本番なので、他の記事もぜひ楽しみにしていてください！！
前回の記事はこちら👇
AI駆動開発センター エンジニアの藤崎が、「AIエージェントそのもの」ではなく、「AIエージェントを安全に動かす実行基盤（ランタイム・サンドボックス）」について解説しています！
今回のテーマは、メンバーがそれぞれ好きな技術を好きに語る「技術での自己紹介」です。
アーキテクチャやアルゴリズムのような込み入った技術の話はエンジニアの皆さんにお任せして、私はBiz職の視点から技術を語ってみようと思います。
取り上げるのは、「Harness Engineering（ハーネスエンジニアリング）」という設計のアプローチです。
元々はコーディングエージェントの文脈で提唱された概念ですが、自分のコンサル業務と照らし合わせてみると、思っていた以上に共通点がありました。
この記事では、ハーネスエンジニアリングがPMOやプロジェクト推進の仕事にどう当てはまるのか、そして実際に自分が試している内容も交えながら、どう実務で活かせるのかを考えていきます。
サマリー
- Harness Engineering（ハーネスエンジニアリング）は、モデルそのものではなく、ツール・権限・検証・ログ・実行ルールなどの外側を設計する考え方です。
- この発想は、進め方の原則を置き、危険信号を見張り、決まった手順を回す——という、PMOやプロジェクト推進型のコンサル業務と相性がいいです。
- ただし、「AIにPMOを任せる」という話ではなく、人間が見ていたリスク・未決事項・意思決定のズレを、AIも扱える形（判断の原則・危険信号の検知・定型の手順）に分解していくことが大事です。
- 最後に残る論点は、どこをAIに委ね、どこを人間が握るか。AI時代のBiz業務では、その線引きを感覚ではなく仕組みとして設計する力が重要になります。
Harness Engineeringとは
まず、Harness Engineering（ハーネスエンジニアリング）そのものについて、簡単に整理します。
「harness（ハーネス）」は、元々「馬具」や「安全帯」を指す言葉です。
AIの文脈では、LLM（大規模言語モデル）の周りを取り囲む仕組みの総称として使われています。
Birgitta Böckelerの整理（martinfowler.com に掲載）によると、以下のように定義されています。
**harness とは、AIエージェントのうち「モデルそのものを除いた、すべて」を指す略語として定着してきました。
つまり、ツール、実行ループ、渡すコンテキスト、出力の検証ゲート、権限の制御、ログの監視。
こうしたモデルの外側の設計全部**が、harnessです。
Agent（エージェント）＝ Model（モデル：賢さ）＋ Harness（外側の設計）
この考え方は、2026年2月にOpenAIのRyan Lopopoloや、HashiCorp共同創業者（Terraformなどで知られる）のMitchell Hashimotoあたりが発信して、そこから一気に広がりました。
ハーネスの中身は、大きく2種類に分けられます。
- ガイド（feedforward）：動く前に方向を示すもの。ルールや前提
- センサー（feedback）：動いた後に異常を拾うもの。検証や検知
エージェントがミスをするたびに、二度と同じミスをしないよう環境側を直していき、賢さ（モデル）を上げるのではなく、周りの環境を整えてミスが起きないようにする、という発想です。
なぜ今、この言葉が出てきたのか
そもそも、なぜ「ハーネス」という言葉が注目され始めたのか、ここ数年のAI設計の流れを振り返ってみます。
AIに対して「どこを設計するか」は、この数年で内側から外側へ移ってきました。
時期
設計の対象
ひとことで
〜2024
プロンプト
モデルに打ち込む言葉そのもの。チャットの時代
2025
コンテキスト
プロンプトの周りの情報。何を渡すかを設計する
2026〜
ハーネス
モデルの外側の環境全部。ツール・検証・権限・監視
この移り変わりは「チャット → エージェント」への進化とちょうど重なっています。
一問一答のチャットなら、いいプロンプトを書ければ十分でした。
しかし、AIが自分でツールを使い、コードを書き、何手も先まで自律的に動く「エージェント」になると、言葉だけでは制御しきれません。
だから、外側の環境そのものを設計する「ハーネス」が必要になってきました。
コンテキストエンジニアリングを体系化したAnthropic（2025年9月）も、設計の主役を「単発のチャット」から「ツールを自律的に使い続けるエージェント」へと移す前提で語っています。
Bizの業務における「ハーネスエンジニアリング」とは？
コーディングエージェントの「周辺」を設計して、安全に賢く動かそうとする仕組みを知った時、私はこう思いました。
「PMOやプロジェクト推進を担うコンサルがやっている仕事に近いのではないか」
PMIが提唱しているPMO（Project Management Office）の定義を見ると、PMOは「プロジェクトのガバナンスを標準化し、進め方やツールを共有する組織構造」とされています。
噛み砕くと、PMOや、プロジェクト推進に入るコンサルが担っているのは、
- 進め方の原則を決める（運営方針、リスク管理方針）
- 進捗・リスク・課題・意思決定を見張る
- ヌケモレや認識ズレを検知する
- 必要なときに決まった手順を回す（議事録整理、週次報告）
のような業務です。
先ほどのハーネスの構造とほぼ似ていませんか？
ガイド（動く前）とセンサー（動いた後）に、それを実際に回す手順（スキル）を加えると、ちょうどこう対応します。
翻訳全文
原則＝ガイド、見張り・検知＝センサー、手順＝スキル。
逆に、PMO やプロジェクト推進寄りのコンサル業務は元々「人間が回している制御システム」に近い仕事だったと言えます。
これらの観点をすべて人間の頭だけで考え続ける/見張り続けるのは、現実にはなかなか難しいことです。期限が静かに溶け、リスクが「対応中」のまま止まり、決めたはずの方針がいつの間にかズレ、答えの出ていない問いが議事録の隅に取り残されていく。こうした「危険信号」を、人間がすべてリアルタイムで拾うのには無理があります。
だからこそ、ここに AI エージェントを組み込んだハーネスを活かせるのではないかと考えました。
実際、AI×PMO のプロダクトはすでに出てきていて、たとえば Acuity PPM は、リスク調査・ステータスレポート作成・ガバナンス文書生成・依存関係の監視などを、エージェントが代行する機能を持っています。「人間の PMO では手が回らない監視・統合作業を AI が担う」という方向性は、もう始まっています。
Claude Code の仕組みを、PMO の業務に置き換える
例えば Claude Code には、エージェントの挙動を外側から設計するための機能がいくつか用意されています。これらを PMO の業務に対応させると、こうなります。
Claude Code の機能
PMO・プロジェクト推進側
役割
rules
運営原則・リスク管理方針・共有ルール
動く前に判断基準をそろえる
hooks
危険信号の検知
期限超過や未対応リスクを拾う
skills
業務手順
議事録整理、WBS 更新、週次報告などを回す
これらは、ひとつのフォルダ構成にまとめて運用できます。PMO やプロジェクト推進の業務をハーネス化するなら、たとえばこんなディレクトリ構成が考えられます。
my-project/
├── CLAUDE.md ← プロジェクトの前提・運営原則（メモリ）
├── .claude/
│ ├── rules/ ← 判断のよりどころになる原則
│ │ ├── pm-principles.md ← 常に効く運営原則
│ │ └── risk-management.md ← state/RISK.json を触るときだけ効く（paths指定）
│ ├── hooks/ ← 自動実行（セッション管理・危険信号の検知）
│ ├── skills/ ← 業務手順（議事録整理・WBS 更新・週次報告 など）
│ └── settings.json ← hooks の登録
├── docs/ ← 人間向けドキュメント（Markdown）
│ ├── PROJECT.md
│ ├── STAKEHOLDER.md
│ └── COMMUNICATION.md
├── state/ ← AI 向けの構造化データ（JSON）
│ ├── STATUS.json
│ ├── RISK.json
│ ├── WBS.json
│ └── CHANGELOG.json
├── meeting/ ← 議事録（YYYY-MM-DD_会議名.md）
└── workspace/ ← 作業成果物（下書き・レポート）
それぞれの要素は次のような役割を担います。
rules（運営原則）＝ ガイド
Claude Code では、判断のよりどころになる原則を、rules（.claude/rules/ 配下の Markdown ファイル）として置いておけます。risk-management.md のように、トピックごとにファイルを分けて書いておく仕組みです。
PMO の仕事でいうと、ここに入るのはプロジェクトの運営原則・リスク管理方針・共有ルールです。「高リスクは緩和策とセットでしか登録しない」といった、判断の前提にあたります。
たとえば、プロジェクトの運営原則を rules 的に書くなら、こんな内容になります。
PM Principles
業務目的
- 守る: 認識齟齬の最小化、意思決定の追跡可能性、リスク早期検出
- 守らない: フォーマット美化、全タスク詳細追跡、予算管理
- 人が介入: 外部送信前、リスク優先度、スコープ変更、ハーネス変更
行動原則
- 意思決定はユーザーに委ねる。提案は出すが勝手に決めない
- 不確実性がある場合は必ず明示する
- 成功時は静かに、異常検出時は詳しく報告する
- 外部コミュニケーションは AI が下書き、人間が確認・送信
- 高リスクには必ず対応策 (mitigation) を定義する
「何を守って、何を守らないか」「どこは人間が決めるか」を最初に宣言しておく。
プロジェクト推進でいう運営方針を、エージェントにも効くように言語化したもの、と捉えてもらえれば近いです。
さらに便利なのが、ルールの適用範囲をパスで絞れることです。フロントマターに paths を指定すると、そのルールは該当するファイルを触ったときだけ読み込まれます。たとえばリスク管理表（state/RISK.json）を編集するときだけ効くルールは、こう書けます。
paths:
- "state/RISK.json"
リスク登録のルール
- 高リスク（impact=high）は、対応策 (mitigation) が空欄のまま登録しない
- ステータスを30日以上更新していないリスクは「要再評価」とする
こうしておくと、関係する作業のときだけ判断基準が差し込まれ、それ以外の場面では文脈を余計に膨らませずに済みます（paths を書かないルールは、常に読み込まれます）。無駄なコンテキストを使わずに AI に指示を送ることができるようになります。
hooks（危険信号センサー）＝ センサー
hooks は、特定のタイミングで自動的に走る仕組みです（公式には「ライフサイクルの特定時点で実行されるユーザー定義のコマンド」）。
PMO の仕事では、これが危険信号の自動検知にあたります。
- 期限超過
- 未対応リスク
- 方針のズレ（Decision Drift）
- 放置された問い（Open Question Aging）
仕掛けはシンプルで、settings.json に「いつ・何を走らせるか」を登録しておくだけです。
{
"hooks": {
"SessionStart": [
{
"matcher": "startup|resume",
"hooks": [
{
"type": "command",
"command": "$CLAUDE_PROJECT_DIR/.claude/hooks/session-start.sh"
}
]
}
],
"PreToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "$CLAUDE_PROJECT_DIR/.claude/hooks/approval-gate.sh"
},
{
"type": "command",
"if": "Write(**/state/*.json)",
"command": "$CLAUDE_PROJECT_DIR/.claude/hooks/validate-state.sh"
}
]
}
]
}
}
SessionStart（セッションの開始・再開時）に状況チェックを走らせ、PreToolUse（ファイルを書き換える直前）に承認ゲートと検証を挟むことで、人間が「そろそろリスクを見直さなければ」と思い出さなくても、仕組みの側が自動で見張ってくれる状態になります。
たとえば作業を開き直すと、ターミナルにこんな状況が出ます（数字や名前は例です）。
翻訳全文
ポイントは、スキル（手順書）はあくまで「何を危険とみなすか」を宣言するだけ、という点です。
「高リスクなのに対応策が空欄」のデータをそもそも保存させないのは、先ほどの PreToolUse フック（validate-state.sh）と、状態データ側のスキーマ検証の役割です。スキルが基準を示し、フックとスキーマがそれを強制する。そういう分担です。
これはプロジェクト推進でよく起きる「リスク管理表、対策欄が空っぽ問題」を、人間の注意力に頼らず仕組みで潰しにいっている、ということです。
docs / state（情報の置き場）
コードではありませんが、もうひとつ大事なのが、情報の置き場を docs（人間が読む Markdown）と state（AI が読み書きする構造化 JSON）に分けておくことです。同じ情報でも、人間が判断するために読むものと、AI が安全に処理するものは、形が違っていい。この切り分けも、ハーネス設計の一部だと考えています。
こうして組み上げた全体は、ざっくり予防・検知・改善の 3 層で整理できます。
- 予防：そもそも事故が起きない形にする。高リスクは緩和策がないと保存できない、AI は外部に直接送信できない、決定の履歴は追記のみ。
- 検知：動いた後の異常を拾う。セッションごとのルールチェックに加え、LLM（大規模言語モデル）による深いレビュー、さらに別モデルでのクロスレビューと、段階を分けて見張る。
- 改善：見つかった不具合を改善リストに溜め、週次で振り返り、ハーネス自体を直していく。
「ミスが起きたら、出力ではなく仕組みの方を直す」——このループが、ハーネスエンジニアリングの肝だと考えています。一度仕組みに落とせば、同じ見落としは二度と起きません。
大事なのは「これが PM やコンサルを代替するものではない」という点です。AI が人間の代わりに意思決定する道具ではなく、人間が危険信号に気づきやすくするための制御レイヤー（control layer）だと考えています。
ハーネスにどこまで任せるべきか
ここまで「相性がいい」と書いてきましたが、すべてをハーネスで制御させることにも限界があると思っています。
大事なのは「ハーネス化できるかどうか」ではなく、「どこまでをハーネスに任せ、どこからを人間が握るか」です。その線引きを考えるうえで、特に意識しておきたいことが 3 つあります。
1. 確信を持って下す判断は、ハーネスにはできない
センサーが拾えるのは、期限・リスク・未回答の問いのような「形にできる危険信号」だけです。
クライアントとの信頼関係、社内の力学、そして「ここはこう進めるべきだ」と確信を持って下す最後の意思決定——コンサルの価値の核心にあるこうした部分は、数値化しにくいまま仕組みの外に残ります。ハーネスはそこを代わりに考えてはくれません。
2. 検知を増やしすぎると、誰も見なくなる
センサーは足すほど良いわけではありません。
アラートが多すぎれば、結局すべてが無視されます。だから rules に「守らないこと」をわざわざ書いています。何を検知しないかを決めるのも、ハーネス設計の一部です。
3. 「楽になる」とは限らない
翻訳全文
AI に任せれば速くなる、と単純には言えません。
ハーネスは作って終わりではなく、ルールを足し、検知を調整し、ズレを直し続ける対象です。作業そのものは減っても、仕組みを設計し育てるコストは、人間が払い続けることになります。
ハーネスは「万能の自動化」ではありません。
任せられる範囲を広げながらも、最後の判断と「何を任せないか」は人間が持ち続ける——その前提は持ち続ける必要があります。
おわりに
設計の対象は、プロンプトからコンテキストへ、そしてハーネスへと、これからも移り変わっていきました。AI の進化に伴ってその対象はこれからも変わっていくと考えています。
しかし、その中で、「どこを人間が握り、どこを AI や仕組みに委ねるか」を決める設計判断だけは人がし続けるべきことだと思っています。
PMO やプロジェクト推進に関わるコンサルが、作業そのものを AI に渡せるようになっても、「どこに線を引くか」という判断は人間に残ります。むしろ、任せられる範囲が広がるほど、その線引きの価値は上がっていく。
Algomatic の強みは、Biz 側の業務設計に強みがあるメンバーと、技術に強いエンジニアが同じチームで議論できることです。
技術側の知見を取り入れながら、「どこを AI に委ね、どこを人間が握るか」を感覚ではなく仕組みとして設計していく。そんな AI ネイティブな業務設計を、これから実際に形にしていきたいと思っています。
ここまで読んでいただきありがとうございました！
最先端の技術に興味があるエンジニアはもちろん、「AI ネイティブな業務設計」を、自分の業務で試すだけでなく、お客様の現場で形にしたい。そんなコンサルタント・PM を Algomatic では募集しています。
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
参考文献
ハーネスエンジニアリング
- Birgitta Böckeler, "Harness engineering for coding agent users"（martinfowler.com, 2026 年 4 月）— https://martinfowler.com/articles/harness-engineering.html
- OpenAI（Ryan Lopopolo）, "Harness engineering: leveraging Codex in an agent-first world"（2026 年 2 月）— https://openai.com/index/harness-engineering/
- Mitchell Hashimoto, "My AI Adoption Journey"（2026 年 2 月）— https://mitchellh.com/writing/my-ai-adoption-journey
プロンプト → コンテキスト → ハーネスの系譜
- Anthropic の「AI エージェントのための効果的なコンテキストエンジニアリング」（2025 年 9 月）— https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Andrej Karpathy による「コンテキストエンジニアリング」に関する投稿（X、2025 年 6 月）— https://x.com/karpathy/status/1937902205765607626
Claude Code 公式ドキュメント
- Hooks リファレンス — https://code.claude.com/docs/en/hooks
- スキル — https://code.claude.com/docs/en/skills
- メモリ（CLAUDE.md / ルール）— https://code.claude.com/docs/en/memory
コンサル/PMO
- PMI の「プロジェクト管理オフィス」 — https://www.pmi.org/learning/project-management-offices
- Acuity PPM（AI と PMO を組み合わせたプロダクトの例）— https://acuityppm.com/
原文を表示
Algomatic コンサルタントの小笠原理久（@rik423__ai）です。
Algomatic 初夏のアドベントカレンダー、5日目です。
季節外れのアドカレですが、スタートからまだたった5日目。ここからが本番なので、他の記事もぜひ楽しみにしていてください！！
前回の記事はこちら👇
AI駆動開発センター エンジニアの藤崎が、「AIエージェントそのもの」ではなく、「AIエージェントを安全に動かす実行基盤（ランタイム・サンドボックス）」について解説しています！
今回のテーマは、メンバーがそれぞれ好きな技術を好きに語る 「技術での自己紹介」。
アーキテクチャやアルゴリズムのような込み入った技術の話はエンジニアの皆さんにお任せして、私はBiz職の視点から技術を語ってみようと思います。
取り上げるのは、「Harness Engineering（ハーネスエンジニアリング）」という設計のアプローチです。
元々はコーディングエージェントの文脈で提唱された概念ですが、自分のコンサル業務と照らし合わせてみると、思っていた以上に共通点がありました。
この記事では、ハーネスエンジニアリングがPMOやプロジェクト推進の仕事にどう当てはまるのか、そして実際に自分が試している内容も交えながら、どう実務で活かせるのかを考えていきます。
サマリー
- Harness Engineeringは、モデルそのものではなく、ツール・権限・検証・ログ・実行ルールなどの外側を設計する考え方
- この発想は、進め方の原則を置き、危険信号を見張り、決まった手順を回す——という、PMOやプロジェクト推進型のコンサル業務と相性がいい
- ただし、「AIにPMOを任せる」という話ではなく、人間が見ていたリスク・未決事項・意思決定のズレを、AIも扱える形（判断の原則・危険信号の検知・定型の手順）に分解していくことが大事
- 最後に残る論点は、どこをAIに委ね、どこを人間が握るか。AI時代のBiz業務では、その線引きを感覚ではなく仕組みとして設計する力が重要になる
Harness Engineeringとは
まず、Harness Engineeringそのものについて、簡単に整理します。
「harness（ハーネス）」は、元々「馬具」や「安全帯」を指す言葉です。
AIの文脈では、LLM（モデル）の周りを取り囲む仕組みの総称として使われています。
Birgitta Böckelerの整理（martinfowler.com に掲載）によると、以下のように定義されています。
harness とは、AIエージェントのうち「モデルそのものを除いた、すべて」を指す略語として定着してきた。
つまり、ツール、実行ループ、渡すコンテキスト、出力の検証ゲート、権限の制御、ログの監視。
こうしたモデルの外側の設計全部が、harnessです。
Agent ＝ Model（賢さ）＋ Harness（外側の設計）この考え方は、2026年2月にOpenAIのRyan Lopopoloや、HashiCorp共同創業者（Terraformなどで知られる）のMitchell Hashimotoあたりが発信して、そこから一気に広がりました。
ハーネスの中身は、大きく2種類に分けられます。
- ガイド（feedforward）：動く前に方向を示すもの。ルールや前提
- センサー（feedback）：動いた後に異常を拾うもの。検証や検知
エージェントがミスをするたびに、二度と同じミスをしないよう環境側を直していき、賢さ（モデル）を上げるのではなく、周りの環境を整えてミスが起きないようにする、という発想です。
なぜ今、この言葉が出てきたのか
そもそも、なぜ「ハーネス」という言葉が注目され始めたのか、ここ数年のAI設計の流れを振り返ってみます。
AIに対して「どこを設計するか」は、この数年で内側から外側へ移ってきました。
| 時期 | 設計の対象 | ひとことで |
|---|---|---|
| 〜2024 | プロンプト | モデルに打ち込む言葉そのもの。チャットの時代 |
| 2025 | コンテキスト | プロンプトの周りの情報。何を渡すかを設計する |
| 2026〜 | ハーネス | モデルの外側の環境全部。ツール・検証・権限・監視 |
この移り変わりは「チャット → エージェント」への進化とちょうど重なっています。
一問一答のチャットなら、いいプロンプトを書ければ十分でした。
しかし、AIが自分でツールを使い、コードを書き、何手も先まで自律的に動く「エージェント」になると、言葉だけでは制御しきれません。
だから、外側の環境そのものを設計する「ハーネス」が必要になってきました。
コンテキストエンジニアリングを体系化したAnthropic（2025年9月）も、設計の主役を「単発のチャット」から「ツールを自律的に使い続けるエージェント」へと移す前提で語っています。
Bizの業務における「ハーネスエンジニアリング」とは？
コーディングエージェントの「周辺」を設計して、安全に賢く動かそうとする仕組みを知った時、私はこう思いました。
「PMOやプロジェクト推進を担うコンサルがやっている仕事に近いのではないか」
PMIが提唱しているPMO（Project Management Office）の定義を見ると、PMOは「プロジェクトのガバナンスを標準化し、進め方やツールを共有する組織構造」とされています。
噛み砕くと、PMOや、プロジェクト推進に入るコンサルが担っているのは、
- 進め方の原則を決める（運営方針、リスク管理方針）
- 進捗・リスク・課題・意思決定を見張る
- ヌケモレや認識ズレを検知する
- 必要なときに決まった手順を回す（議事録整理、週次報告）
のような業務です。
先ほどのハーネスの構造とほぼ似ていませんか？
ガイド（動く前）とセンサー（動いた後）に、それを実際に回す手順（スキル）を加えると、ちょうどこう対応します。
原則＝ガイド、見張り・検知＝センサー、手順＝スキル。
逆に、PMOやプロジェクト推進寄りのコンサル業務は元々「人間が回している制御システム」に近い仕事だったと言えます。
これらの観点をすべて人間の頭だけで考え続ける/見張り続けるのは、現実にはなかなか難しいことです。期限が静かに溶け、リスクが「対応中」のまま止まり、決めたはずの方針がいつの間にかズレ、答えの出ていない問いが議事録の隅に取り残されていく。こうした「危険信号」を、人間がすべてリアルタイムで拾うのには無理があります。
だからこそ、ここにAIエージェントを組み込んだハーネスを活かせるのではないかと考えました。
実際、AI×PMOのプロダクトはすでに出てきていて、たとえばAcuity PPMは、リスク調査・ステータスレポート作成・ガバナンス文書生成・依存関係の監視などを、エージェントが代行する機能を持っています。
「人間のPMOでは手が回らない監視・統合作業をAIが担う」という方向性は、もう始まっています。
Claude Codeの仕組みを、PMOの業務に置き換える
例えばClaude Codeには、エージェントの挙動を外側から設計するための機能がいくつか用意されています。
これらをPMOの業務に対応させると、こうなります。
| Claude Codeの機能 | PMO・プロジェクト推進側 | 役割 |
|---|---|---|
| rules | 運営原則・リスク管理方針・共有ルール | 動く前に判断基準をそろえる |
| hooks | 危険信号の検知 | 期限超過や未対応リスクを拾う |
| skills | 業務手順 | 議事録整理、WBS更新、週次報告などを回す |
これらは、ひとつのフォルダ構成にまとめて運用できます。
PMOやプロジェクト推進の業務をハーネス化するなら、たとえばこんなディレクトリ構成が考えられます。
my-project/
├── CLAUDE.md ← プロジェクトの前提・運営原則（メモリ）
├── .claude/
│ ├── rules/ ← 判断のよりどころになる原則
│ │ ├── pm-principles.md ← 常に効く運営原則
│ │ └── risk-management.md ← state/RISK.json を触るときだけ効く（paths指定）
│ ├── hooks/ ← 自動実行（セッション管理・危険信号の検知）
│ ├── skills/ ← 業務手順（議事録整理・WBS更新・週次報告 など）
│ └── settings.json ← hooks の登録
├── docs/ ← 人間向けドキュメント（Markdown）
│ ├── PROJECT.md
│ ├── STAKEHOLDER.md
│ └── COMMUNICATION.md
├── state/ ← AI向けの構造化データ（JSON）
│ ├── STATUS.json
│ ├── RISK.json
│ ├── WBS.json
│ └── CHANGELOG.json
├── meeting/ ← 議事録（YYYY-MM-DD_会議名.md）
└── workspace/ ← 作業成果物（下書き・レポート）それぞれの要素は次のような役割を担います。
rules（運営原則）＝ ガイド
Claude Codeでは、判断のよりどころになる原則を、rules（.claude/rules/ 配下のMarkdownファイル）として置いておけます。risk-management.md のように、トピックごとにファイルを分けて書いておく仕組みです。
PMOの仕事でいうと、ここに入るのはプロジェクトの運営原則・リスク管理方針・共有ルールです。「高リスクは緩和策とセットでしか登録しない」といった、判断の前提にあたります。
たとえば、プロジェクトの運営原則を rules 的に書くなら、こんな内容になります。
# PM Principles
## 業務目的
- 守る: 認識齟齬の最小化、意思決定の追跡可能性、リスク早期検出
- 守らない: フォーマット美化、全タスク詳細追跡、予算管理
- 人が介入: 外部送信前、リスク優先度、スコープ変更、ハーネス変更
## 行動原則
- 意思決定はユーザーに委ねる。提案は出すが勝手に決めない
- 不確実性がある場合は必ず明示する
- 成功時は静かに、異常検出時は詳しく報告する
- 外部コミュニケーションはAIが下書き、人間が確認・送信
- 高リスクには必ず対応策(mitigation)を定義する
「何を守って、何を守らないか」「どこは人間が決めるか」を最初に宣言しておく。
プロジェクト推進でいう運営方針を、エージェントにも効くように言語化したもの、と捉えてもらえれば近いです。
さらに便利なのが、ルールの適用範囲をパスで絞れることです。フロントマターに paths を指定すると、そのルールは該当するファイルを触ったときだけ読み込まれます。たとえばリスク管理表（state/RISK.json）を編集するときだけ効くルールは、こう書けます。
---
paths:
- "state/RISK.json"
---
# リスク登録のルール
- 高リスク（impact=high）は、対応策(mitigation)が空欄のまま登録しない
- ステータスを30日以上更新していないリスクは「要再評価」とする
こうしておくと、関係する作業のときだけ判断基準が差し込まれ、それ以外の場面では文脈を余計に膨らませずに済みます（paths を書かないルールは、常に読み込まれます）。無駄なコンテキストを使わずにAIに指示を送ることができるようになります。
hooks（危険信号センサー）＝ センサー
hooksは、特定のタイミングで自動的に走る仕組みです（公式には「ライフサイクルの特定時点で実行されるユーザー定義のコマンド」）。
PMOの仕事では、これが危険信号の自動検知にあたります。
- 期限超過
- 未対応リスク
- 方針のズレ（Decision Drift）
- 放置された問い（Open Question Aging）
仕掛けはシンプルで、settings.json に「いつ・何を走らせるか」を登録しておくだけです。
{
"hooks": {
"SessionStart": [
{
"matcher": "startup|resume",
"hooks": [
{
"type": "command",
"command": "$CLAUDE_PROJECT_DIR/.claude/hooks/session-start.sh"
}
]
}
],
"PreToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "$CLAUDE_PROJECT_DIR/.claude/hooks/approval-gate.sh"
},
{
"type": "command",
"if": "Write(**/state/*.json)",
"command": "$CLAUDE_PROJECT_DIR/.claude/hooks/validate-state.sh"
}
]
}
]
}
}
SessionStart（セッションの開始・再開時）に状況チェックを走らせ、PreToolUse（ファイルを書き換える直前）に承認ゲートと検証を挟むことで、人間が「そろそろリスクを見直さなければ」と思い出さなくても、仕組みの側が自動で見張ってくれる状態になります。
たとえば作業を開き直すと、ターミナルにこんな状況が出ます（数字や名前は例です）。
[ブランド刷新PJ]
doing: 提案書ドラフト作成
OVERDUE(1):
- 競合調査レポート (2026-05-28) +4d
TODO(3):
[*] 提案書ドラフト (~06-05)
[ ] 見積もり確定 <- 提案書ドラフト
OpenQuestion(1):
- 予算上限が未回答のまま（3日経過）
RISK(1):
[schedule] デザイン確定が後工程をブロック
DRIFT(1):
- 「まずMVPで合意」のはずが、全機能実装の議論が進行中（[*] は着手中・[ ] は未着手、<- は依存関係（例：「見積もり確定」は「提案書ドラフト」待ち）、+4d は期限から4日超過を表します。）
会議の冒頭で「いま危ないのはここ」と人間が整理していた作業を、セッションの開始時に自動でやってくれます。
たとえば上の例の「予算上限が未回答のまま3日経過」という一行は、先ほど挙げた Open Question Aging（放置された問い）を検知してくれています。
skills（業務手順）＝ スキル
skillsは、必要なときだけ呼び出される手順書のようなものです。このskillを毎回読み込むことで、同じ型に沿ってエージェントに作業をさせることができます。
PMOの仕事でいうと、以下のような定型的なタスクがあります。
- 議事録の取り込み
- WBSの更新
- リスクチェック
- 週次レポート生成
たとえば「リスクチェック」を」行うためのスキルを作ろうとすると、こんなふうに作ることができます（先頭の --- で囲んだ部分がYAMLフロントマターで、description や when_to_use を見てClaudeが「いつこのスキルを使うか」を判断します。今回の場合は、「リスク」のような言葉が含まれていた時に読み込むようになっています）。
---
name: risk-check
description: Re-evaluate existing risks, detect new ones, and verify mitigations. Use when reviewing or updating the project's risk list.
when_to_use: 「リスクチェックして」「リスク確認」「リスク評価」のとき
allowed-tools: Read, Grep
---
## ワークフロー
1. 既存リスクの再評価（impact / probability、対応策の進捗）
2. 新規リスクの検出（スケジュール / リソース / 外部依存）
3. 対応策（mitigation）の確認
## チェック観点
- 高リスクなのに対応策が未定義のリスクを洗い出す
- リスク件数が前回から急増していないか
- 30日以上更新されていないリスクがないか
ポイントは、スキル（手順書）はあくまで「何を危険とみなすか」を宣言するだけ、という点です。
「高リスクなのに対応策が空欄」のデータをそもそも保存させないのは、先ほどの PreToolUse フック（validate-state.sh）と、状態データ側のスキーマ検証の役割です。スキルが基準を示し、フックとスキーマがそれを強制する。そういう分担です。
これはプロジェクト推進でよく起きる「リスク管理表、対策欄が空っぽ問題」を、人間の注意力に頼らず仕組みで潰しにいっている、ということです。
docs / state（情報の置き場）
コードではありませんが、もうひとつ大事なのが、情報の置き場を docs（人間が読むMarkdown）と state（AIが読み書きする構造化JSON）に分けておくことです。同じ情報でも、人間が判断するために読むものと、AIが安全に処理するものは、形が違っていい。この切り分けも、ハーネス設計の一部だと考えています。
こうして組み上げた全体は、ざっくり予防・検知・改善の3層で整理できます。
- 予防：そもそも事故が起きない形にする。高リスクは緩和策がないと保存できない、AIは外部に直接送信できない、決定の履歴は追記のみ。
- 検知：動いた後の異常を拾う。セッションごとのルールチェックに加え、LLMによる深いレビュー、さらに別モデルでのクロスレビューと、段階を分けて見張る。
- 改善：見つかった不具合を改善リストに溜め、週次で振り返り、ハーネス自体を直していく。
「ミスが起きたら、出力ではなく仕組みの方を直す」——このループが、ハーネスエンジニアリングの肝だと考えています。一度仕組みに落とせば、同じ見落としは二度と起きません。
大事なのは「これがPMやコンサルを代替するものではない」という点です。AIが人間の代わりに意思決定する道具ではなく、人間が危険信号に気づきやすくするための制御レイヤーだと考えています。
ハーネスにどこまで任せるべきか
ここまで「相性がいい」と書いてきましたが、すべてをハーネスで制御させることにも限界があると思っています。
大事なのは「ハーネス化できるかどうか」ではなく、「どこまでをハーネスに任せ、どこからを人間が握るか」です。その線引きを考えるうえで、特に意識しておきたいことが3つあります。
1. 確信を持って下す判断は、ハーネスにはできない
センサーが拾えるのは、期限・リスク・未回答の問いのような「形にできる危険信号」だけです。
クライアントとの信頼関係、社内の力学、そして「ここはこう進めるべきだ」と確信を持って下す最後の意思決定——コンサルの価値の核心にあるこうした部分は、数値化しにくいまま仕組みの外に残ります。ハーネスはそこを代わりに考えてはくれません。
2. 検知を増やしすぎると、誰も見なくなる
センサーは足すほど良いわけではありません。
アラートが多すぎれば、結局すべてが無視されます。だから rules に「守らないこと」をわざわざ書いています。何を検知しないかを決めるのも、ハーネス設計の一部です。
3. 「楽になる」とは限らない
AIに任せれば速くなる、と単純には言えません。
ハーネスは作って終わりではなく、ルールを足し、検知を調整し、ズレを直し続ける対象です。作業そのものは減っても、仕組みを設計し育てるコストは、人間が払い続けることになります。
ハーネスは「万能の自動化」ではありません。
任せられる範囲を広げながらも、最後の判断と「何を任せないか」は人間が持ち続ける——その前提は持ち続ける必要があります。
おわりに
設計の対象は、プロンプトからコンテキストへ、そしてハーネスへと、これからも移り変わっていきました。AIの進化に伴ってその対象はこれからも変わっていくと考えています。
しかし、その中で、「どこを人間が握り、どこをAIや仕組みに委ねるか」を決める設計判断だけは人がし続けるべきことだと思っています。
PMOやプロジェクト推進に関わるコンサルが、作業そのものをAIに渡せるようになっても、「どこに線を引くか」という判断は人間に残ります。むしろ、任せられる範囲が広がるほど、その線引きの価値は上がっていく。
Algomaticの強みは、Biz側の業務設計に強みがあるメンバーと、技術に強いエンジニアが同じチームで議論できることです。
技術側の知見を取り入れながら、「どこをAIに委ね、どこを人間が握るか」を感覚ではなく仕組みとして設計していく。そんなAIネイティブな業務設計を、これから実際に形にしていきたいと思っています。
ここまで読んでいただきありがとうございました！
最先端の技術に興味があるエンジニアはもちろん、「AIネイティブな業務設計」を、自分の業務で試すだけでなく、お客様の現場で形にしたい。そんなコンサルタント・PMを Algomatic では募集しています。
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
参考文献
ハーネスエンジニアリング
- Birgitta Böckeler, "Harness engineering for coding agent users"（martinfowler.com, 2026年4月）— https://martinfowler.com/articles/harness-engineering.html
- OpenAI（Ryan Lopopolo）, "Harness engineering: leveraging Codex in an agent-first world"（2026年2月）— https://openai.com/index/harness-engineering/
- Mitchell Hashimoto, "My AI Adoption Journey"（2026年2月）— https://mitchellh.com/writing/my-ai-adoption-journey
プロンプト → コンテキスト → ハーネスの系譜
- Anthropic, "Effective context engineering for AI agents"（2025年9月）— https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Andrej Karpathy, "context engineering" について（X, 2025年6月）— https://x.com/karpathy/status/1937902205765607626
Claude Code 公式ドキュメント
- Hooks reference — https://code.claude.com/docs/en/hooks
- Skills — https://code.claude.com/docs/en/skills
- Memory（CLAUDE.md / rules）— https://code.claude.com/docs/en/memory
コンサル/PMO
- PMI, "Project Management Offices" — https://www.pmi.org/learning/project-management-offices
- Acuity PPM（AI×PMOプロダクトの例）— https://acuityppm.com/
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み