AIに同じ指示を繰り返していないか？組織の知識を「仕組み」に変える方法

AIエージェントを使っていると、同じ説明を何度もしていることがあります。

「このプロジェクトでは、そのライブラリは使わないでください」

「変更したら、このテストも実行してください」

「公開やデプロイは、必ず人間の承認を取ってください」

その場では修正されるので、仕事は進みます。ところが、新しいチャットや別のエージェントでは、また同じ説明が必要になる。以前指摘した失敗も、別の場所で繰り返されます。

これではAIによって一件ずつ仕事は速くなっても、組織全体の仕事の仕方はあまり改善していません。

Claude Codeの発案者であり、現在その責任者を務めるBoris Cherny氏は、2026年7月16日のXへの投稿で、この問題を取り上げました。Cherny氏の主張は、単に「AIをもっと使おう」という話ではありません。

まず、元の投稿を掲載します。

この投稿を私なりに一文へまとめると、次のようになります。

私は、この考え方はソフトウェア開発だけに限らないと思っています。

営業、採用、研修、コンテンツ制作、福祉、医療、現場改善。仕事の中に「うちではこうする」「ここで人間が確認する」「この失敗は避ける」という判断があるなら、同じ問題が存在します。

優れたエンジニアは、以前から自分の仕事を仕組みに変えてきた

Cherny氏の主張は、AIによって突然生まれたものではありません。

以前から優れたエンジニアは、目の前の機能を作るだけでなく、今後の仕事を速く、正確にする仕組みも作ってきました。

たとえば、エディタ操作の自動化、コードの問題を見つけるリントルール、不具合を検出する自動テスト、ビルドや公開を自動化するCI、繰り返し使えるテンプレートなどです。

一件の機能開発は、一件分の成果を生みます。

一方、一つの自動テストやリントルールは、その後の数十回、数百回の変更に効きます。そのため、自分の作業を仕組みに変えることは、以前から大きな効果を持つ活動でした。

AIエージェントが加わると、この効果の範囲がさらに広がります。

従来

人間
×
その人が作った自動化

AIエージェント時代

人間
×
複数のAIエージェント
×
自動化
×
組織の知識

一つのテスト、一つのルール、一つの作業手順が、人間だけでなく、同じ環境で動く複数のAIにも適用されます。

つまり、AI時代の自動化は、自分一人の速度を上げる活動ではありません。チームで働く人間とAIの両方を底上げする活動になっています。

同じ問題をAIに直させ続けても、組織は賢くならない

たとえば、AIが社内の設計ルールと異なるコードを書いたとします。

レビューで指摘し、AIへ修正させれば、その変更は直せます。しかし、これだけでは同じ問題がまた起きます。

毎回AIに判断させる運用には、次の弱点が残るからです。

• そのたびに時間とトークンを使う

• AIが問題を見落とす可能性がある

• 指示する人によって結果が変わる

• 別のセッションへ学びが残らない

• レビュー担当者が同じ指摘を繰り返す

そこで、同じ問題が起きないように、知識を別の形へ変換します。

命名規則なら、検査スクリプトやリントルールにする。

必要なテストが決まっているなら、CIで自動実行する。

推奨する実装方法があるなら、テンプレートやSkillにする。

危険な操作なら、権限や承認フローで止める。

違いは次のとおりです。

個別対応

問題が起きる
↓
レビューで発見する
↓
AIへ修正を依頼する
↓
その一件だけ直る

構造的な対応

問題が起きる
↓
なぜ起きたかを分析する
↓
ルール・テスト・手順へ反映する
↓
次回から検出または防止する

言い換えるなら、AIに一つの問題を解かせるだけでなく、その種類の問題が繰り返されにくい環境を作るということです。

OpenAIもCodexのベストプラクティスで、繰り返し使う指示をAGENTS.mdへ保存し、環境や設定を標準化することを勧めています。また、CodexのSkillsは、指示、参考資料、必要に応じたスクリプトを一つの再利用可能な単位としてまとめる仕組みです。

自動化できるのは、単純作業だけではなくなった

以前の自動化は、比較的ルールを決めやすい作業が中心でした。

コードの整形、型の確認、テスト、ビルド、公開、決められた形式へのデータ変換などです。

AIエージェントの登場によって、対象はもう少し曖昧な知識へ広がりました。

たとえば、次のようなものです。

• なぜこのフレームワークを使うのか

• どのような設計を優先するのか

• どの場面で例外を認めるのか

• 最初にどの資料を読むべきか

• 変更時にどの影響範囲を確認するのか

• この製品で守るべき体験上の原則は何か

• 過去にどのような失敗が起きたのか

• レビューでは何を重く見るのか

これまでは、長く在籍している人の頭の中にしかないことも少なくありませんでした。

その結果、新しい人は「レビューで指摘されて初めて知る」「詳しい人へ聞かないと進めない」という状態になります。AIエージェントも同じです。利用できる場所に知識がなければ、それを前提に仕事はできません。

Cherny氏が述べている「ドメイン知識をインフラにする」とは、こうした知識を、たとえば次のような形へ移すことです。

AGENTS.md・CLAUDE.md
設計ドキュメント
Skills
実装テンプレート
コードコメント
テスト
レビュー基準
メモリ
運用手順書

ただし、ここで注意が必要です。

文章を書いて保存しただけでは、まだ十分な仕組みとは言えません。

知識を「書く」だけでなく、「実行・強制・改善」できる状態へ

知識の仕組み化には、いくつかの段階があります。

1．文章として残す

このプロジェクトでは、AではなくBを使う

まずは、人の頭の中から外へ出します。

2．必要なときにAIが参照できるようにする

AGENTS.mdや設計文書から発見できる状態にする

毎回チャットで説明しなくても、AIが自分でたどり着けるようにします。

3．作業手順として再利用できるようにする

SkillやCommandに確認項目、変更手順、テスト方法をまとめる

知識を読むだけでなく、一定の順序で実行できる状態です。

4．違反を自動的に検出・防止する

リント、型、テスト、CI、権限、Hookで制約する

「守ってください」と頼むだけでなく、違反したときに検出したり、危険な操作を止めたりします。

5．結果から仕組み自体を改善する

評価結果、レビュー、失敗ログを分析し、
ルールやテストを更新する

使うたびに問題を見つけ、次回の環境へ反映します。

OpenAIの開発チームは、すべての知識を巨大なAGENTS.mdへ詰め込む方式を試したものの、うまくいかなかったと報告しています。

情報が多すぎると、本来のタスクやコードを読む余地が減ります。すべてが重要と書かれていれば、本当に優先すべきことも分かりません。大きな説明書ほど古い情報が残りやすく、内容が正しいかを検査することも難しくなります。

そこで同チームは、短いAGENTS.mdを詳細情報へ案内する「目次」として使い、設計資料、計画、品質基準などを構造化された文書へ分けています。さらに、文書の鮮度やリンクをリントとCIで検査しています。

つまり、重要なのは大量の文章を残すことではありません。

AGENTS.md
→ 入口と恒久的なルール

Skills
→ 繰り返す作業の手順

参考資料
→ 詳細な知識

スクリプト
→ 機械的に実行する処理

テスト・Eval
→ 結果の品質確認

権限・Hook
→ 禁止事項と承認境界

Runbook
→ 異常時の対応

というように、知識の性質に合った場所へ分ける必要があります。

重要なのは「知識量」より、判断の流れを再現できること

組織には大量の情報があります。しかし、すべてをAIへ渡せば、仕事が安定するわけではありません。

実務で本当に必要なのは、ある状況で、

• 何を確認するか

• どの選択肢を選ぶか

• どの条件で止まるか

• どの操作に承認が必要か

• 失敗したときにどう戻すか

を再現できることです。

たとえば、システムを本番へ公開するための知識を100ページ保存しても、安全な運用になるとは限りません。

必要なのは、次のような判断経路です。

変更内容を確認する
↓
事前検査を行う
↓
差分とテスト結果を提示する
↓
人間が承認する
↓
本番へ反映する
↓
正常に動くか確認する
↓
問題があれば元へ戻す

ここで仕組み化されているのは操作だけではありません。

誰が、どの段階で、何を確認し、どこから責任を引き受けるのかが定義されています。

私は、SNS投稿などの外部へ影響する処理でも、次のように段階を分けています。

試行
↓
下書き
↓
人間の承認
↓
公開
↓
結果確認
↓
必要なら取り消し・修正

AIへ実行を任せても、公開や送信などの不可逆な判断まで自動的に任せる必要はありません。

この意味で、知識のインフラ化とは、単にAIが読む文書を増やすことではなく、正しい判断経路と責任の境界を、繰り返し実行できる形にすることです。

AIを何度も動かすことと、改善が蓄積することは別である

AIエージェントに、目標を達成するまで作業を繰り返させる「ループ」も注目されています。

しかし、反復回数を増やすだけで、AIや組織が自動的に賢くなるわけではありません。

質の高いループには、少なくとも次の要素が必要です。

目標
↓
現在の状態を確認
↓
次の行動を決める
↓
実行
↓
結果を検証
↓
目標との差を判断
↓
継続・修正・停止

特に不足しやすいのは、成功条件、失敗条件、停止条件、検証方法、状態の保存方法、人間へ戻す条件です。

Anthropicの長時間エージェントに関する報告でも、単に同じエージェントを長く動かすのではなく、作業状態を次のセッションへ残すことや、成果物を作る役割と評価する役割を分けることが重視されています。エージェントを評価する場合も、モデル単体ではなく、ツールや実行ループを含むハーネス全体を評価する必要があると説明されています。

したがって、

反復 ＝ 改善

ではありません。

反復
＋
評価
＋
状態の保存
＋
仕組みの更新
＝
次回へ残る改善

です。

同じセッションの中で何度修正しても、その学びがルール、テスト、Skill、運用手順などへ反映されなければ、別のセッションでは同じ失敗が起こり得ます。

レビューで指摘された問題は、すべて自動化すべきなのか

Cherny氏は投稿の中で、正しいフレームワークや設計パターンを知らず、コードレビューで拒否されるような状況を「自動化の失敗」と表現しています。

この見方には重要な示唆があります。

正しいやり方がレビュー担当者の頭の中にしかなければ、新しい参加者もAIも、作業前には知ることができません。

その場合、一件のコードを直すだけで終えず、次のような改善を検討すべきです。

• 原則をプロジェクトルールへ残す

• 正しい実装例をSkillやテンプレートにする

• 禁止するライブラリを自動検出する

• 必要なテストを自動実行する

• PR作成時にレビュー基準を検査する

ただし、私は「レビュー指摘はすべて自動化できる」とは考えていません。

新しい設計、複数の正解がある問題、経営上の優先順位、微妙な利用者体験、倫理的な判断などは、事前に一つのルールへ固定できないからです。

実務上は、次のように捉えるのが妥当です。

一度しか起きない、高度に状況依存する問題まで、無理に自動化する必要はありません。

何を仕組みにし、何を人間へ残すべきか

あらゆる知識をルールにすると、別の問題が起きます。

ルールが増えすぎれば、互いに矛盾する。

以前は正しかった知識が古くなる。

状況ごとの例外に対応できなくなる。

一度しか使わない仕組みの保守に、かえって時間がかかる。

誤った判断をルール化すれば、その誤りが組織全体へ広がる。

そこで、自動化する対象は、次の四つの軸で判断するのがよいと考えています。

発生頻度
×
失敗したときの損失
×
機械的に判定できる度合い
×
再利用できる範囲

ここから、仕組みを作るための実装・保守コストを差し引きます。

高頻度で、失敗の影響が大きく、判定しやすく、広く再利用できるものほど、自動化に向いています。

反対に、次のようなものは人間の判断を残した方が安全です。

• 一度しか起きない問題

• 状況によって答えが大きく変わる判断

• 短期間で前提が変化する領域

• 経営、倫理、契約、公開に関する判断

• 正解を事前に定義できない新しい問題

自動化の最大の価値は、速度より「参加しやすさ」にある

Cherny氏の投稿で、私が特に重要だと感じたのは、新しいエンジニアや非エンジニアもコードベースへ貢献しやすくなるという指摘です。

非エンジニアが開発へ参加しにくい理由は、コードの文法を知らないことだけではありません。

• どの設計が採用されているか分からない

• どこを変更すべきか分からない

• 変更の副作用が分からない

• 組織固有のルールが分からない

• 何をテストすべきか分からない

という、組織や製品に固有の文脈が不足しているからです。

こうした知識が発見可能になり、作業手順と検証方法が整っていれば、新しい社員、経験の浅い人、外部パートナー、非エンジニア、AIエージェントが、安全に参加できる範囲は広がります。

これは「AIがあれば誰でもすぐエンジニアになれる」という意味ではありません。

ということです。

AIがもたらす価値を、時間やコストの削減だけで見ると、この点を見落とします。

知識の仕組み化は、

• 誰が仕事へ参加できるか

• 誰の知識を改善へ取り込めるか

• 特定の人が不在でも仕事を進められるか

• 新しい人が成果を出すまでの時間を短くできるか

を変えます。

つまり、これは組織への参加コストを下げる技術でもあります。

開発以外の仕事でも、同じことが起きている

この考え方は、ソフトウェア開発に限りません。

たとえば、記事制作で次の問題が繰り返されているとします。

• 重要な出典が抜ける

• 文章が報告書のように冷たくなる

• 画像の挿入場所が分からなくなる

• 画像のファイル名がランダムになる

• 公開前の確認が漏れる

そのたびに記事を修正するだけでは、次の記事でまた起きます。

そこで、

• 調査と出典の管理方法

• 記事のBrief

• ライティングスタイル

• 画像の命名規則

• 原稿中の画像挿入位置

• 公開前チェックリスト

• 完了条件

として残します。

さらに、ファイル名を自動検査したり、出典セクションの有無を確認したり、公開前に人間の承認を必須にしたりすれば、文章から実行可能な仕組みへ進みます。

現場改善でも同様です。

現場の会話を記録する
↓
文字へ変換する
↓
AIが論点を整理する
↓
人間が事実を確認する
↓
問題を分類する
↓
改善タスクへ変える
↓
会議で優先順位を決める
↓
現場へ結果を返す

これは議事録作成の自動化だけではありません。

現場で起きている問題や、個人の中にある知識を、組織の改善へ接続する仕組みです。

AI時代には「知識負債」が積み上がる

ここからは、Cherny氏の投稿を起点にした私自身の整理です。

ソフトウェア開発には「技術的負債」という言葉があります。短期的な都合で不完全な設計を積み重ねた結果、将来の変更が難しくなる状態です。

AIを利用する組織では、これに加えて知識負債が問題になると考えています。

たとえば、次のような状態です。

• 重要な判断が特定の人の頭にしかない

• 文書と実際の運用が一致していない

• 同じレビュー指摘が繰り返される

• 新しい人が毎回同じ失敗をする

• AIへ毎回同じ説明をしている

• エージェントが同じ誤実装を繰り返す

• ルールが増えすぎて優先順位が分からない

• 古い知識が削除されず残っている

知識負債が大きい組織へAIを増やすと、必ずしも改善するとは限りません。

AIは、良い仕組みだけでなく、組織内の曖昧さ、矛盾、古い前提も速く広げるからです。

OpenAIのハーネスエンジニアリングの事例でも、エージェントが既存パターンを複製することで、品質上のずれが広がる問題が取り上げられています。その対策として、品質基準を機械的に検査し、継続的に修正する運用が説明されています。

したがって、「AIを導入する前に業務を整理する」だけでは足りません。

AIを使うほど組織が賢くなる状態を作る

単発のAI利用では、成果は一回ごとに完結します。

AIを使う
↓
成果物ができる
↓
終了

仕組みが整っている場合は、仕事の経験が次回へ残ります。

AIを使う
↓
成果物ができる
↓
失敗や不足が見つかる
↓
ルール・手順・テストを改善する
↓
次回の成功率が上がる

この違いは、利用回数が増えるほど大きくなります。

将来、組織間の差を生むのは、最新のAIモデルへアクセスできるかどうかだけではないでしょう。多くの組織が、似たモデルやツールを利用できるようになるからです。

差がつくのは、次の点だと私は考えています。

毎回ゼロから指示する組織と、失敗や判断を仕組みへ変える組織では、同じAIを使っていても、時間がたつほど成果の安定性が変わります。

私が「AI業務ハーネス」と呼んでいるもの

私は、AIを仕事の中で安定して動かすための仕組み全体を、AI業務ハーネスと呼んでいます。

ここでいうハーネスは、AIの力を業務の目的へ接続し、動ける範囲や確認方法を定める仕組みです。

構成要素は、単一のプロンプトではありません。

モデル
×
ツール
×
コンテキスト
×
ルール
×
権限
×
作業手順
×
評価
×
改善ループ

具体的には、次のようなものを含みます。

• AIが参照する知識

• タスクごとの作業手順

• 使用できるツール

• 変更してよい範囲

• 人間の承認が必要な操作

• 品質を判断する基準

• テストや確認方法

• 異常時の停止条件

• 実行履歴

• 失敗から得た教訓

• ルールを更新する方法

これは単なるナレッジ共有ではありません。

経験を言葉にする
↓
判断基準を構造化する
↓
手順として実行可能にする
↓
必要な制約を強制する
↓
結果を評価する
↓
次の仕組みへ反映する

という一連の設計です。

まずは「何度も説明していること」を一つ探す

いきなり大量のルールや文書を作る必要はありません。

最初に探すべきなのは、次のようなものです。

• AIへ毎回説明していること

• 新しい人へ毎回説明していること

• レビューで何度も指摘していること

• 繰り返し発生しているミス

• 特定の人にしか判断できないこと

• 外部へ出す前に必ず確認していること

• 失敗すると大きな損失が出ること

• 完了したか判断しにくいこと

見つけた問題を、性質に応じて変換します。

知識が見つからない
→
文書や参考資料にする

同じ説明を繰り返している
→
プロジェクトルールにする

作業手順が毎回同じ
→
Skillやテンプレートにする

違反を機械的に判断できる
→
リント、テスト、CIにする

危険な操作がある
→
権限と承認フローで止める

品質が安定しない
→
評価基準と検証手順を作る

同じ失敗が続く
→
原因を分析し、仕組みを更新する

最初から完璧な環境を作ろうとすると、かえってルールが増えすぎます。

まず一つ、繰り返している問題を選ぶ。

仕組みに変える。

実際に使う。

本当に改善したかを確認する。

必要なら直す。

この小さな循環から始める方が現実的です。

AI時代の自動化は、次の人が働きやすい環境を作ること

従来の優れた人は、自分の作業を自動化してきました。

AI時代には、そこからもう一段進む必要があります。

1. 自分の作業を自動化する

2. AIが行う作業も標準化する

3. AIの失敗を次回から防ぐ

4. 判断基準を人の頭の外へ出す

5. 新しい人が参加しやすい環境を作る

6. 人間が責任を持つ境界を明確にする

7. 使うほど仕組みが改善する循環を作る

私は、Cherny氏の投稿を次のように受け取りました。

さらに広げるなら、こう言えます。

AIの本当の価値は、目の前の仕事を一回代行することだけではありません。

人間とAIが仕事をするたびに、その組織の仕事の仕方自体を改善できることにあります。

AI時代の競争力は、「AIを使えるか」だけでは決まりません。

ここに、大きな差が生まれると私は考えています。

出典・参考資料

• Boris Cherny, Xへの投稿。エンジニアが以前から行ってきた自動化を、AIエージェントとドメイン知識のインフラ化へ広げる提言。2026年6月30日。

• Anthropic, “Claude Code for Service Delivery: Learn from Boris Cherny.” Boris Cherny氏をClaude Codeの発案者、Head of Claude Codeとして紹介。2026年1月27日。

• OpenAI, “Harness engineering: leveraging Codex in an agent-first world.” リポジトリ内知識、短いAGENTS.md、機械的な検査、品質改善ループに関する実践報告。2026年2月11日。

• OpenAI Developers, “Customization – Codex.” AGENTS.md、メモリ、Skills、MCP、サブエージェントの役割。

• OpenAI Developers, “Agent Skills – Codex.” 指示、参考資料、スクリプトを含む再利用可能なSkillの公式説明。

• Anthropic, “Effective harnesses for long-running agents.” 長時間タスクにおける状態の引き継ぎと段階的な作業。2025年11月26日。

• Anthropic, “Harness design for long-running application development.” 生成役と評価役を分離した反復設計。2026年3月24日。

• Anthropic, “Demystifying evals for AI agents.” エージェントの評価では、モデルだけでなくハーネス全体を評価するという整理。2026年1月9日。