業務別フォルダ設計とエージェント運用のプラクティス

前回の「AI活用の差は、組織の運用設計で決まる」では、AI活用の差を生むのは外枠（ハーネス）の設計であり、それは言語化・フロー化・置き場所の三段階で進められる、という話をしました。今回はその続きとして、置き場所の設計を具体的なパターンに落とし込みます。

扱うのは五つです。業務の種類ごとのフォルダ構成、エージェントへの役割の振り方、定義ファイルに書くべき内容、モデルの使い分け、そして運用を続けると必ず起きるフォルダの肥大化への対処。最後の章では、私が自分の環境を実際に測って分かった数字を出します。理屈としては正しそうに見えた運用案が、実測すると前提から崩れた――という話です。

フォルダ設計の三原則

具体的なパターンに入る前に、前提となる原則を三つ挙げます。

原則1：フォルダは、AIに読ませる単位である

これが最も大きな発想の転換です。

少し前まで、ファイル整理の推奨はむしろ逆でした。「検索とリンクがあるのだから、フォルダを細かく作り込む必要はない」。これは正しい助言でした。ただし、人間が使う前提での話です。

AIに読ませるようになると前提が変わります。フォルダの区切りが、そのままAIが一度に見る範囲を決めてしまうからです。関係のないものが同じフォルダに入っていれば、AIはそれも読みます。逆に、必要なものが別フォルダに散っていれば、渡し忘れが起きます。整理の仕方が、そのまま出力の精度に効いてくる。この前提の変化は、ほんの半年ほどで起きました。

つまり、人が見て整理されている構成と、AIに読ませて有効な構成は、必ずしも一致しません。日付別・部署別といった人間都合の分類は、AIにとっては意味のない区切りになりがちです。

原則2：人の領域とAI専用領域を分ける

作業中の下書き、判断材料のメモ、個人的な走り書き――これらは人間の領域です。一方、AIに参照させることを前提に整えた資料は別の領域に置きます。両者を混ぜると、AIが未確定の下書きを確定情報として扱ってしまいます。

原則3：確定した資料は、コピーではなく移動で「昇格」させる

これは実務で効きます。下書きが固まったら、AI参照用の領域へ移動する。コピーにすると、同じ内容の新旧二つが残り、どちらが正しいのかAIには判断できません。「昇格」という言葉を使うと、この操作が権限の変更を伴うことも意識しやすくなります。

補足として、権限の広げすぎ――いわゆるオーバーシェアリングにも触れておきます。AIに読ませるために共有範囲を広げるのは、最も安易で最も危険な近道です。読ませたい情報だけを昇格させる運用にしておけば、範囲を広げる必要はありません。

業務別のフォルダ構成パターン四案

原則を踏まえて、業務の種類ごとにパターンを考えてみます。業務によってAIに任せられる範囲が違うため、構成も変わるはずだからです。

パターンA：ドキュメント業務（提案書・報告書・議事録）

案件名/
├── 指示書        ← 書式・トーン・禁止事項
├── 参照資料/     ← 確定した情報のみ（AI領域）
├── 作業中/       ← 下書き・メモ（人の領域）
└── 成果物/       ← 完成した提出物

この業務の肝は書式の統一です。参照資料に過去の完成版を入れておくと、AIがそれを見本にできます。逆に、作業中の下書きが参照資料に混ざると精度が一気に落ちます。原則3の「昇格」を最も厳格に運用すべきなのがこのパターンです。

なお、前回触れた「文体ルールを渡しても200件中196件が同じ結末になった」という実測を踏まえると、指示書に書くだけでは書式は揃いません。過去の完成版という見本を置くこと、そして納品前に形式を確認する工程を挟むことが、実際には効きます。

パターンB：開発（設計から実装・テストまで）

プロジェクト/
├── 指示書        ← 技術規約・テスト基準
├── docs/         ← 要件・設計・テスト仕様
├── src/
└── tests/

開発の特徴は、工程間の依存が強いことです。設計を変えたのにテスト仕様が古いままだと、AIは古い前提で実装します。そのため、どの工程のドキュメントを更新すべきかを指示書に明記しておくのが有効です。私の環境では「どんなに小さな変更でも影響するドキュメントは必ず更新する」というルールを指示書に入れています。

パターンC：調査・情報収集

テーマ/
├── 収集/         ← 生データ（記事・文字起こし）
├── まとめ/       ← テーマ別に統合したノート
└── アーカイブ/   ← 統合済みの原本

このパターンの要点は、生データを消さずに退避させることです。収集したものをそのまま溜め続けると読めなくなり、かといって統合時に消すと出典をたどれなくなります。統合したらアーカイブへ移し、まとめ側から原本へリンクを張る。この三段構成にしておくと、量が増えても破綻しません。

私はこの構成を実際に運用していて、直近では記事のクリップ46件と動画ノート33件をまとめて統合し、28のテーマノートに集約しました。原本は一件も消していません。この記事で引用している事例の多くも、そのアーカイブから引いています。

パターンD：定型運用（日次・週次で回るもの）

運用名/
├── 手順書        ← 実行手順と判断基準
├── 設定/         ← ワークフロー定義
└── 実行結果/     ← ログ・生成物

定型運用で最も重要なのは、失敗したときに気づける設計です。毎日動くものは、動かなかったことに気づきにくい。私は以前、週次で動かしていた情報収集が失敗しているのに一週間気づきませんでした。原因は、失敗しても誰にも通知が飛ばない設定になっていたことです。手順書には正常時の手順だけでなく、異常時に誰がどう気づくかまで書いておくべきです。

エージェントへの役割の振り方

置き場所の三つめ、エージェントの話に移ります。役割を切り出して専門の担当を作る考え方です。

まず「増やせば賢くなる」を疑う

最初に押さえておきたい前提があります。使える道具や担当を増やせばAIは賢くなる、という直感は外れます。

これを的確に指摘した記事がありました。ツール連携を設計するとき、最初のデモは問題なく動く。ところがツールが増えていくと、AIは選択を誤り始める――という構造的な問題です。選択肢が増えるほど、選択そのものが難しくなる。人間の組織で、部署を増やせば増やすほど「どこに相談すればいいか分からない」状態になるのと同じです。

さらに率直な指摘もあります。サブエージェントの設計パターンを整理した記事は、この機能を**「知ってはいるが、結局メインの会話で全部やってしまう」機能の代表格**だと表現していました。これは私も身に覚えがあります。

切り出す価値があるもの・ないもの

では、何を切り出すのか。私は次の基準で判断しています。

切り出す価値があるもの

探索の範囲が広い作業。大量のファイルを横断して探すような処理は、結論だけ受け取れば十分で、途中経過を手元に残す必要がありません。コンテキストを汚さずに済むのが最大の利点です
判断基準が独立している作業。品質レビューのように「作った人とは別の視点で見る」ことに意味がある処理
権限を絞りたい作業。調査専門の担当に書き込み権限を与えない、といった分離ができます

切り出さないほうがよいもの

文脈を共有していないと判断できない作業。前提の受け渡しコストが、切り出す利益を上回ります
一往復で終わる小さな作業。起動のオーバーヘッドのほうが大きくなります

「専門家をたくさん」だが、いきなり組織化しない

エージェントの設計思想として参考になったのが、セキュリティ側からの整理です。スーパーAIを一つ作ろうとせず、最小単位で構築して「専門家をたくさん作る」イメージで設計する、というもの。一つの万能な担当より、権限の狭い専門家を並べたほうが、事故の影響範囲を閉じ込められます。

ただし、ここで慎重になるべき実測もあります。複数のエージェントで「プレジデント→ボス→ワーカー三人」という組織構造を作り、自律的に開発させた実験の記録です。結果として、発表者自身が「組織構築はまだ難しく、ベストプラクティスは見つかっていない」と明言しています。完成度は体感60〜70%で、残りは人間が詰める必要があった。そして並行して動かすとトークン消費が激しく、レートリミットに到達したとも。

そこで示されていた結論が実践的でした。いきなり組織化せず、うまくいった流れを後から自動化するほうが出戻りが少ない。 前回触れた「最初からループ化しない」という話と、まったく同じ構造です。

エージェントの前に、手順書で足りないかを考える

もう一つ、順序の話を。繰り返し使う定型手順については、エージェントとして切り出す前に手順書として書けないかを先に検討する価値があります。

近年、この用途に Agent Skills という仕組みが標準化されつつあります。考え方はシンプルで、巨大な指示を常時読ませるのではなく、手順をパッケージ化して外に出しておき、AIが必要なときだけ読みに行くというもの。常時読み込みではないのでトークンを節約でき、内容を差し替えれば最新の手順が反映され、同じ失敗の繰り返しも防げます。

私の環境では、Obsidianの整理、用語集のレビュー、記事のSEO点検といった作業を八件の手順書として持っていますが、これらはエージェントにしていません。同じ文脈の中で手順に従うだけで足りるからです。エージェント化が必要なのは、文脈を分けること自体に意味がある場合だけだと考えています。

定義ファイルに書くべきこと

役割を決めたら、定義として書き出します。Claude Codeの場合、.claude/agents/ にMarkdownファイルを置き、先頭のfrontmatterで属性を、本文で役割の指示を書く形式です。

書くべき項目は五つあると考えています。

1. 名前と、呼び出す条件

何をする担当かに加えて、どういうときに呼ぶかを書きます。ここが曖昧だと、呼ばれるべきときに呼ばれないか、逆に何にでも呼ばれるかのどちらかになります。「〜のときに使う」という条件文の形で書くのが確実です。

2. 使ってよい道具の範囲

ファイルの読み書き、コマンド実行、外部検索など、許可する操作を明示します。役割の定義とは、できることの定義であると同時に、できないことの定義でもあります。 前述の「最小単位で構築する」という思想は、この項目に現れます。

3. 出力の形式

これを書き忘れると、受け取る側で毎回整形する羽目になります。項目名・順序・粒度まで指定しておくと、複数の結果を並べて比較できるようになります。前回触れた「形式が揃っていないと集約できない」という話が、そのまま効いてきます。

4. 使うモデル

次章で詳しく述べます。

5. やってはいけないこと

これが最も抜けやすい項目です。「本番環境には書き込まない」「検証には専用のテスト用IDを使う」といった禁止事項は、役割の説明からは自然に導かれません。明示的に書く必要があります。

指示書を**「AI社員の社則」**として設計する、という考え方を紹介した記事がありました。禁止事項と判断基準を明文化しておくことで、毎回の指示を減らせる、と。社則という比喩が的確なのは、社則が主に「やってはいけないこと」の集合だからだと思います。

私はこの手の禁止事項を、実際に事故を起こしてから追記してきました。検証作業で自分の個人データを復元できない形で上書きしてしまったこともあります。順序としては望ましくありませんが、事故のたびに定義へ書き戻す運用そのものは正しいと思っています。

補足：ファイル名の共通化には注意する

エージェントや指示書の定義ファイルは、ツールによって名前や置き場所の規約が異なります。ここで一つ、知らないと踏む落とし穴があります。

AGENTS.md と CLAUDE.md は、ファイルの探索・解決ルールが逆向きだという指摘です。片方に寄せようとしてシンボリックリンクで共通化すると、意図しない読み込み順が生まれる可能性がある。安易な共通化の前に、それぞれの解決規則を確認したほうがよい、ということです。

複数のツールを併用している環境では、この手の「似ているが違う」規約が事故の温床になります。

モデルとコストの使い分け

エージェントごとに使うモデルを変えられる、という点は見落とされがちですが、運用設計としては重要です。理由は費用と速度の二つです。

すべての処理を最上位モデルで動かすのは、すべての業務を最も単価の高い人材に割り当てるようなものです。軽い処理まで重いモデルに回せば、待ち時間も積み上がります。

私は、次の三層で考えると整理しやすいと感じています。

層	向く処理	考え方
上位	設計判断、原因の特定、レビュー	間違えたときの手戻りが大きい処理
中位	実装、文章作成、要約	量が多く、品質も必要な処理
軽量	収集、整形、分類	判断がほぼ不要で、量だけが多い処理

判断基準はシンプルで、間違えたときの手戻りの大きさです。設計を間違えると、その後の実装がすべて無駄になります。一方、分類を間違えても直せば済みます。手戻りが大きい処理にだけ上位モデルを充てる、という配分が現実的です。

なお、この使い分けは指示書に書いておくこともできます。私は「計画は上位モデル、実行は中位モデル」という方針を指示書に一行書いておくことで、都度指定しなくても切り替わるようにしています。

コストを下げる三方向

モデルの選択以外にも、費用を下げる打ち手があります。集めた事例を整理すると、方向は三つに分かれました。

一つめは、入力を削る。 渡すコンテキストを検索で絞り込むことで、トークン消費を30%削減したという実測がありました。前章のサブエージェントによる「コンテキストを汚さない」も、同じ方向の打ち手です。

二つめは、接続先を替える。 ツールはそのままに、裏で動くモデルだけを作業ごとに切り替える構成です。安価なモデルへ振れば同じ作業が1/6〜1/14の単価になるという記録がありました。

三つめは、ローカルへ逃がす。 簡易なタスクだけを手元で動くモデルにオフロードし、外部APIの消費を抑える構成です。

三つとも発想は同じで、処理の重さと単価を対応させることに尽きます。一律に最上位を使うのをやめるだけで、費用は大きく変わります。

肥大化への対処――実測してみたら前提が崩れた話

最後に、運用を続けると必ず起きる問題を扱います。増え続ける、という問題です。

増えるものは二つあります。指示書の中身と、フォルダそのものです。

指示書の肥大化には、階層化が効く

前者から。指示書が肥大化すると、関係のない作業のときにも毎回読み込まれ、コンテキストを浪費します。対策として有効なのが階層化で、上位ルール・レビュー観点などのリソース・技術別の詳細、という三層に分割して、実測で83%軽量化したという記録がありました。

私も同じ構造を採っています。常に読ませる上位ルールは薄く保ち、詳細は該当する作業のときだけ読み込ませる。この設計については基礎編・応用編で詳しく書きました。

フォルダの肥大化――思いついた案は、実測で崩れた

後者のフォルダについて、私が考えていた対処案はこうでした。作業が終わったプロジェクトはGitHubへプッシュしたうえでローカルから削除し、手元には現在アクティブなものだけを残す。必要になったらプルして戻す。ローカルを常に軽く保てて、AIに読ませる範囲も自然に絞られる。理屈としては筋が通っているように見えます。

実際に自分の環境を測ってみたところ、この案は前提から崩れました。分かったことを三つ挙げます。

落とし穴1：ignoreされたファイルは、プッシュされていない。

あるブログ用フォルダに201MBのバックアップがありました。ところがGitHubに乗っていたのは小さなJSONファイル五件だけで、本体であるデータベースのエクスポートと全体バックアップは、設定ファイルで除外対象になっていました。つまりローカルにしか存在しない。「プッシュ済みだから消しても戻せる」という前提は、この201MBには最初から成立していませんでした。

落とし穴2：更新が止まっていることは、使っていない証拠にならない。

十六個のプロジェクトのうち十一個は、七月三十一日を最後に一度もコミットされていませんでした。素直に見れば非アクティブです。ところが調べてみると、そのうち九個は別のアプリケーションから十一本のシンボリックリンクで実行時に参照され続けていました。 消せばアプリが壊れます。コミット履歴は編集の記録であって、使用の記録ではなかったわけです。

落とし穴3：削除しても、容量の利益はほとんどない。

全体で2.4GB。うち2.1GB、実に88%が、仮想環境やライブラリのキャッシュ、ビルド結果といったいつでも再生成できるものでした。純粋なソースと資産は300MB程度しかありません。しかもディスクの空きは1.1TBあります。容量問題は、そもそも存在していませんでした。

目的を置き換えると、設計が変わる

三つを踏まえると、この構想の目的は「ディスクの節約」ではなかったと分かります。本当の目的は、AIに読ませる範囲と、探すときの見通しを管理することでした。目的が変われば設計も変わります。整理し直すと、こうなります。

再生成できるものは、いつでも消してよい。gitの管理とは無関係に扱える。ここが容量の大半を占める
削除の判断は、コミット履歴ではなく参照関係で行う。他から参照されているものは、更新が止まっていても現役
除外設定されたファイルは、消す前に別途退避する。プッシュされていないものは、プッシュ済みとは別に扱う
アーカイブの本命は、参照されていない完了済みプロジェクト。私の環境では二つ該当し、合計1.6GBでした

この四つは、実測しなければ一つも出てきませんでした。

後日談――この手順で、実際に畳んだ

この整理を書いた後、私はこの四つの手順に沿って、その十一個のプロジェクト群を実際に畳みました。参照を先に外し、除外設定されていたデータ（ゲームのセーブデータが含まれていました）を退避してから、ローカルとリモートを削除しています。うち二つだけは今も使っていたので、参照の切れない形に置き直して残しました。

結果として、指示書は二十ファイルから八ファイルへ、AIが毎回読み込む索引は四十六項目から二十八項目へ減りました。容量よりも、この「毎回読み込まれる量」が減ったことのほうが体感で効いています。 冒頭に書いた「フォルダはAIに読ませる単位である」という原則は、畳むときにも同じように効くということです。

思えば、似た話を読んだことがあります。四つのAIに企画をレビューさせたところ、当初の壮大な構想の九割が削られ、残ったのは小さなツールひとつだったという記録です。作る前に検証すると、たいてい構想は縮みます。縮むこと自体が成果だ、とも言えます。

おわりに

フォルダ設計の三原則、業務別の四パターン、エージェントの切り出し方と定義の書き方、モデルとコストの三層、そして肥大化への対処。ここまでが、前回の「外枠の層」を具体化した内容です。

ここに挙げたパターンがそのまま当てはまる環境はないはずです。業務の性質も、扱う情報の機密度も、人数も違います。一つの参考として見ていただければと思います。

ただ、最後の章の話だけは、どんな環境にも当てはまると思っています。運用設計は、思いついた案をそのまま導入せず、一度自分の環境を測ってから決める。 私の場合、それをやらなければ、消してはいけない201MBを消していました。