こんにちは、株式会社TIMEWELLの濱本です。「AIネイティブ新規事業開発の方法論」の最終回です。私は大企業で新規事業を10年以上手がけ、大企業100社以上が参加した挑戦者支援プログラム「CHANGE by ONE JAPAN」の運営責任者を務め、いまは起業家と社内起業家向けのAI駆動開発プログラム「WARP ENTRE」を運営しています。第1回から第3回で、聞く、仮説にする、文書にする、の順に書いてきました。最終回は、それらを「一度きり」ではなく「毎週、安定して」回すための仕組みの話です。
シリーズ「AIネイティブ新規事業開発の方法論」 ①顧客インタビュー中にモックを作る技術 ②リーンキャンバス・7 Powers・デザインコンセプトを1日で回す ③仕様駆動開発（SDD）の再注目と、文書がコードになる時代 ④AGENTS.md・Skills・Hooks・cronで組織のコンテキストを育てる（この記事）
新規事業の仕事には、一度きりの仕事と、繰り返す仕事があります。インタビューの抽出、仮説台帳の更新、競合の動きの監視、週次の進捗報告、経営会議向けの資料の下書き。繰り返す仕事をエージェントに任せると、最初の1回はうまくいき、3回目あたりから質がぶれ始めます。原因は、ほとんどの場合、プロンプトではありません。エージェントが読んでいる「文脈」が、初回のまま古くなっているか、余計なものを含んでいるか、そもそも組織の文脈を読んでいないかのどれかです。
以前コンテキストエンジニアリング入門で、宮大工の棟梁の「段取り八分」にたとえて、一撃で仕事を完遂させるためのコンテキスト設計を書きました。あの記事は、個人が一回の仕事を成功させる話でした。この記事は、その続きで、組織が繰り返す仕事を安定させる話です。自社のチームの現在地は、AIリテラシー診断で確認できます。
要約: 定期実行する仕事の性能は、AGENTS.md（常時読む事実と規約、200行以内）、Skills（必要時だけ読む手順、SKILL.mdと補助スクリプト）、Hooks（文書で止められない操作を機械的に止める）、cron（時刻で起動する）の4部品と、社内の知識をナレッジグラフ化したデータセットで決まります。組織で運用するときの規律は3つ。コンテキストを更新し続ける（同じミスが2回出たら書く）、コンテキスト外の情報を排除する（context rotを防ぐ。コードや資料から導けることは書かない）、スキルの更新頻度を上げる（週次でLintと評価を回す）。これができるかどうかに、安定したパフォーマンスがかかっています。
コンテキストエンジニアリングを「組織の仕組み」として捉え直す
言葉の定義から入ります。2025年6月、ShopifyのCEOトビ・リュトケは、プロンプトエンジニアリングよりコンテキストエンジニアリングという言葉のほうが核心のスキルを表していると書きました。「LLMがそのタスクを解けるように、あらゆるコンテキストを提供する技術」だと1。Andrej Karpathyはこれに「+1」と応じ、コンテキストエンジニアリングを「次のステップのために、コンテキストウィンドウをちょうど適切な情報で満たす繊細な芸術であり科学」と定義したうえで、こう続けました。少なすぎても、間違った形でも性能は出ない。多すぎても、無関係でも、コストは上がり性能は下がる1。
Anthropicは2025年9月の技術記事で、この「多すぎても下がる」を実験的な知見として整理しています。コンテキストは「重要だが有限の資源」であり、トークンが増えるほどモデルがコンテキスト内の情報を正確に想起する能力は落ちます。これを「context rot」と呼び、良いコンテキストエンジニアリングとは「望む結果の確率を最大化する、可能な限り小さな高信号トークンの集合を見つけること」だと述べています2。
ここまでは、一人のエンジニアが一つのアプリを作る話として語られてきました。私が言いたいのは、これを組織の話として読み直す必要がある、ということです。組織には、暗黙の前提が大量にあります。この顧客には敬称をこう使う。この製品名は旧名で呼ばない。稟議は金額でルートが変わる。去年の失敗の理由はこれだった。こうした前提を、エージェントが「毎回、ちょうど適切な量だけ」読める状態にしておくこと。それが、組織のコンテキストエンジニアリングです。プロンプトを上手に書ける人が一人いても、その人が休んだ週に品質が落ちるなら、仕組みになっていません。
4つの部品。AGENTS.md、Skills、Hooks、cron
仕組みは、4つの部品でできています。名前はツールによって少し違いますが、役割は共通です。ここではClaude Codeの公式ドキュメントとオープンな仕様を根拠に、役割で整理します。
| 部品 | 役割 | いつ読まれるか | 中身の性質 |
|---|---|---|---|
| AGENTS.md / CLAUDE.md | 常時の前提。規約、禁止事項、プロジェクトの事実 | 毎セッションの開始時に必ず | 事実。200行以内 |
| Skills（SKILL.md） | 特定の仕事の手順書と補助スクリプト | その仕事が必要になったときだけ | 手順 |
| Hooks | 操作の前後に機械的に走る処理。止める、記録する、通知する | ツール実行の前後、セッション開始時など | 強制 |
| cron / スケジュール | 時刻や間隔で仕事を起動する | 指定した時刻 | 時計 |
AGENTS.mdは、エージェントのためのREADMEです。OpenAIのCodexやGoogleのJulesなど多くのエージェントが読む共通の書式で、6万を超えるオープンソースのプロジェクトが採用しています3。Claude CodeはCLAUDE.mdを読みますが、@AGENTS.mdと書いて取り込めるので、一つの文書を両方に読ませられます4。書き方の要点は、公式ドキュメントに明快に書かれています。目安は1ファイル200行以内。長くなるほどコンテキストを消費し、遵守率が下がる。具体的で、検証できる書き方をする。「コードを綺麗に」ではなく「インデントは2スペース」、「変更をテストして」ではなく「コミット前にnpm testを実行」4。
何を書くべきかの判断基準も、同じドキュメントにあります。エージェントが同じミスを2回目にしたとき。コードレビューで、知っていて当然のことを指摘されたとき。前回のセッションで打った訂正を、今回も打ったとき。新しいメンバーが同じ文脈を必要とするとき。このときだけ書き足す4。裏返せば、それ以外は書かない、ということです。
Skillsは、手順書です。エージェントスキルのオープンな仕様では、スキルはSKILL.mdというファイルを含むフォルダで、名前と説明のメタデータと手順を書き、必要なら実行スクリプトや参照資料、テンプレートを同梱します5。AGENTS.mdとの使い分けは、公式ドキュメントの一文に尽きます。「同じ指示やチェックリスト、複数ステップの手順を繰り返し貼っているとき、またはCLAUDE.mdの一部が事実ではなく手順に育ってしまったときに、スキルを作る。CLAUDE.mdと違い、スキルの本文は使われるときだけ読み込まれる」6。事実は常時読む文書に、手順はスキルに。この分離が、コンテキストを小さく保つ最初の手段です。
Hooksは、強制です。ここが、多くの人が見落とす部品です。Claude Codeの公式ドキュメントは、CLAUDE.mdもメモリも「強制される設定ではなく、文脈として扱う」と明記したうえで、「エージェントの判断にかかわらず操作を止めたいなら、PreToolUseのHookを使う」と案内しています4。文書に「本番環境を触るな」と書いても、それは文脈です。守られる確率は高いものの、保証ではありません。Hookは、ツールが実行される直前に外部のスクリプトを走らせ、条件を満たさなければ止める仕組みなので、保証になります。外部への送信、本番への変更、秘密情報の読み取り。こうした「一度でも間違えたら困る操作」は、文書ではなくHookで止めます。以前Claude Code Hooks完全ガイドで、イベントの種類と書き方をまとめました。
cronは、時計です。Claude Codeには3つの方式があります。セッションを開いたまま繰り返す/loop、自分のマシン上で動くDesktopのスケジュールタスク、そしてAnthropicが管理するクラウドで動くRoutinesです。公式の比較表によれば、クラウド方式はマシンを起動しておく必要がなく、許可プロンプトも出ずに自律的に走り、最短間隔は1時間。ローカルファイルには触れず、新しくクローンした環境で動きます7。無人で走らせる仕事はクラウドに、手元のファイルが要る仕事はDesktopに、という使い分けです。以前Hermes Agentの使い方で紹介したオープンソースのエージェントにも同種のcronがあり、無人実行時に危険なコマンドへ当たった場合は既定で拒否する設計になっています。無人の仕事は、止める線を先に決めておくべきです。これは、どのツールでも同じです。
社内のコンテキストを「ナレッジグラフ化したデータセット」として育てる
4つの部品がそろっても、エージェントが読む「社内の知識」そのものが散らばっていては、毎回ゼロから探すことになります。ここで、私が最も重要だと考えている考え方に触れます。社内のコンテキストを、検索対象の文書の山ではなく、育てていくデータセットとして持つことです。
Karpathyが2026年4月に公開した「LLM Wiki」という短い文書が、この考え方を一番簡潔に示しています。多くの人のLLMと文書の使い方はRAG、つまり質問のたびに生の文書から関連箇所を検索して答える方式で、そこには蓄積がない。彼が提案するのは、LLMが読んだ情報を取り込み、相互にリンクされたMarkdownのwikiを継続的に維持する方式です。新しい情報が入るたびに、LLMが要約し、既存のページを更新し、古い主張と矛盾する箇所に印をつける。「知識は一度コンパイルされ、以後は最新に保たれる」。彼はその構成を「Obsidianがエディタで、LLMがプログラマーで、wikiがコードベース」と表現しました8。
この文書で私が特に重要だと思う点が三つあります。一つは、三層構造です。生の情報源（不変。LLMは読むが書き換えない）、wiki（LLMが所有し、書き、維持する）、そしてスキーマ（CLAUDE.mdやAGENTS.md。wikiの構造と作法を定義する「鍵となる設定ファイル」）。二つ目は、「Lint」という操作です。定期的に、LLMにwikiの健康診断をさせる。ページ間の矛盾、新しい情報源に上書きされた古い主張、リンクのない孤立ページ、言及されているのに専用ページのない概念。三つ目は、業務チームへの適用です。Slackのスレッド、会議の記録、プロジェクト文書、顧客との通話を材料に、人間がレビューしつつLLMが維持する社内wiki8。
「ナレッジグラフ化」とは、この相互リンクを、人名、製品名、顧客名、課題といった実体と、それらの関係として明示的に持つことです。当社のZEROCKは、社内文書をこの形（GraphRAG）で持ち、エージェントが「この顧客と、この製品と、去年の失敗」のつながりをたどれるようにしています。ただ、ここで言いたいのは製品の話ではなく、順番の話です。最初からグラフを作ろうとしないでください。第1回で書いたインタビューの抽出結果、第2回の仮説台帳、第3回の4文書。これらを、まずMarkdownのwikiとして一か所に置き、エージェントに維持させ、週に一度Lintを回す。それだけで、翌週のエージェントは「先週までに分かっていること」を前提に仕事を始められます。グラフは、wikiが育ってから、必要に迫られて張るものです。
組織で運用するときの3つの規律。更新、排除、頻度
ここが、この記事で一番伝えたいことです。個人がコンテキストを整えるのと、組織が運用するのとでは、難しさの質が違います。個人なら、自分の頭の中と文書のずれに気づけます。組織では、書いた人が異動し、前提が変わり、誰も直さないまま文書が残ります。エージェントは、その古い文書を毎回、忠実に読みます。安定したパフォーマンスが出るかどうかは、次の3つにかかっています。
規律1。コンテキストを更新し続ける。 更新の引き金を、先に決めておきます。前述の「同じミスが2回出たら書く」「レビューで指摘されたら書く」「同じ訂正を2回打ったら書く」を、チームのルールにします。誰が書くかも決めます。私の勧めは、エージェントに下書きさせ、人がレビューしてマージする方式です。第3回で書いたとおり、文書はコードです。AGENTS.mdの変更もプルリクエストで差分を見ます。担当者が変わっても、履歴が残ります。
規律2。コンテキスト外の情報を排除する。 更新より難しいのが、削ることです。Anthropicの言うcontext rotは、古い記述、重複、無関係な情報がたまるほど進みます。判断基準は二つ。一つは「コードや資料から導けることは書かない」。Claude Codeの/doctorは、ディレクトリの構成やライブラリの一覧のようにコードから導ける内容を削り、落とし穴、理由、既定と異なる規約だけを残すよう提案します4。この基準を、人が書く文書にも当てはめます。もう一つは「常時読む必要のないものは、パスやスキルに逃がす」。特定のディレクトリでだけ必要な規約は、パス限定のルールとして置けば、該当ファイルを触るときだけ読まれます4。手順はスキルに出します。こうして、常時読む文書を200行以内に保ちます。削るのは怖い作業です。だから、Lintをエージェントにやらせます。「この文書のうち、コードから導ける記述、この半年で参照されていない記述、他の文書と矛盾する記述を挙げてください」。削る判断は人がしますが、候補出しはエージェントの仕事です。
規律3。スキルの更新頻度を上げる。 スキルは手順書なので、業務が変われば古くなります。古い手順書を忠実に実行するエージェントほど、危ないものはありません。Claude Codeの公式ドキュメントには、使われていないスキルを見つける方法と、スキルを評価して改善する手順が用意されています6。私が勧める頻度は週次です。週に一度、その週に使ったスキルの結果を人が採点し、外れた手順を直します。使われなかったスキルは、説明文が悪いか、もう要らないかのどちらかなので、直すか消します。この「週次のLintと採点」が回っている組織と、回っていない組織で、3か月後のエージェントの安定性はまったく違います。
3つの規律に共通するのは、「書く」より「保つ」に重心があることです。最初に立派なAGENTS.mdを書くことは、誰にでもできます。半年後に、それが200行のまま、正しく、矛盾なく保たれているかどうか。組織のAI活用の成否は、そこで決まります。
定期実行の仕事を、4部品で設計してみる
具体例を一つ、通しで示します。第1回で書いた顧客インタビューの抽出と仮説台帳の更新を、毎週金曜に自動で回す仕事です。
まず、AGENTS.mdに事実を書きます。仮説台帳のファイルの場所、台帳の列の意味、「1件の発言で検証済みにしない」という規約、個人情報は伏せ字済みのファイルしか読まないという禁止事項。20行で足ります。次に、抽出の手順をスキルにします。SKILL.mdには、第1回のプロンプトをそのまま置き、引用とタイムスタンプを必須にするルール、モック提示後の発言にフラグを付けるルール、出力の形式を書きます。補助スクリプトとして、文字起こしから個人情報の候補を機械的に検出するものを同梱します。
Hookは二つ置きます。一つは、伏せ字処理が終わっていないファイルをエージェントが読もうとしたら止めるもの。もう一つは、結果をSlackや社外に送る操作の前に、人の承認を要求するものです。文書に「送るな」と書くのではなく、機械的に止めます。最後にcronで、金曜17時にスキルを起動します。無人で走らせるなら、許可プロンプトが出ないクラウド方式を選び、その代わりHookで送信を承認待ちにします。
そして、翌週の月曜。担当者は、エージェントが更新した仮説台帳の差分と、抽出結果を10分で読みます。引用のないインサイトが混ざっていたら、スキルの手順を直します。台帳の列が足りなければ、AGENTS.mdを直します。この10分が、規律1と3の実体です。月に一度は、wiki全体のLintをエージェントに回し、矛盾と古い主張を削ります。これが規律2です。
大企業でこれを回すときの落とし穴は、社内wikiの過去にあります。多くの会社に、誰も更新しなくなった社内wikiがあります。同じことをエージェントで繰り返さないためには、「維持する仕事をエージェントに渡し、人はレビューだけをする」という分担を最初から決めることです。Karpathyの言葉を借りれば、「チームの誰もやりたがらない維持作業をLLMがやるから、wikiは最新に保たれる」8。人がやるのは、レビューと、削る判断です。
WARPでは、この4部品を参加者のテーマで実際に組み、1週間無人で回してみるところまでを扱います。4回のシリーズで書いた方法論の全体は、WARPのページに載せたプログラムの構成に対応しています。
まとめ
繰り返す仕事の性能は、プロンプトではなく、文脈の仕組みで決まります。事実はAGENTS.mdに、手順はSkillsに、止める線はHooksに、時刻はcronに。社内の知識は、検索対象の山ではなく、エージェントが維持し人がレビューするwikiとして育て、必要になったらグラフに張ります。そして、組織で運用するときは、更新し続けること、コンテキスト外の情報を排除すること、スキルの更新頻度を上げることの3つの規律に、すべてがかかっています。
4回のシリーズを通して書いたのは、結局、順番の話でした。聞いてから作ること。作ったものを仮説にすること。仮説を文書にすること。文書を仕組みにして、毎週回すこと。AIは、この順番のどこでも速度を上げてくれますが、順番そのものは決めてくれません。明日やるなら、まず自社のAGENTS.mdを開いて、行数を数えてみてください。200行を超えていたら、コードや資料から導ける行を探すところから始めます。組織のコンテキストの設計を一緒にやりたい方は、個別相談でお話ししましょう。
Footnotes
-
Andrej Karpathy（X、2025年6月25日）「+1 for "context engineering" over "prompt engineering"…」（tobi lutke の6月19日の投稿「the art of providing all the context for the task to be plausibly solvable by the LLM」への応答） ↩ ↩2
-
Effective context engineering for AI agents（Anthropic Engineering、2025年9月29日） ↩
-
AGENTS.md — A simple, open format for guiding coding agents（「used by over 60k open-source projects」、2026年9月12日取得） ↩
-
How Claude remembers your project — Claude Code Docs（CLAUDE.md と auto memory、200行の目安、追加の判断基準、AGENTS.md の取り込み、/doctor、パス限定ルール、「context, not enforced configuration」） ↩ ↩2 ↩3 ↩4 ↩5 ↩6
-
Extend Claude with skills — Claude Code Docs（スキルを作る判断基準、未使用スキルの検出、評価と改善） ↩ ↩2
-
Run prompts on a schedule — Claude Code Docs（/loop、Desktop のスケジュールタスク、クラウドの Routines の比較表） ↩
-
LLM Wiki — A pattern for building personal knowledge bases using LLMs（Andrej Karpathy、GitHub Gist、2026年4月4日） ↩ ↩2 ↩3
