AI作業環境は「置き場所」からつくる — 第二の脳・正典・社員をつないだ構成

AIの作業環境について話すとき、最初に注目されるのはモデルやツールであることが多い。どのAIを使うか、どのエディタと組み合わせるか、どんなプラグインを入れるか。もちろん、それらも大事だ。

ただ、長く使うほど先に効いてくるのは、道具の性能ではなく情報の置き場所だと思うようになった。

AIに仕事を頼むたびに前提を説明し直す。完成した資料がどこにあるか分からない。同じ方針が複数のメモに書かれ、少しずつ内容が違う。会話の中ではうまく進んだのに、次のセッションでは最初からになる。こうした問題は、AIの賢さだけでは解決しない。

必要なのは、AIが最初に読む入口、保存先の地図、情報ごとの正しい置き場所、生データと整理済みナレッジの境界である。言い換えると、AIを導入する前に、AIが迷わず働ける「会社の棚」をつくる必要がある。

僕の環境では、この考え方をClaude Codeの運用全体まで広げている。完成形ではないが、フォルダ、ルール、自動化、タスク管理、AI社員、一次情報の流れがひとつにつながり始めた。この記事では、その現在地を紹介する。

まず「脳」と「実体」を分けた

作業環境の一番大きな分け方は、00_masterと01_projectの2つである。

00_masterは第二の脳だ。自分の方針、会社の情報、事業の考え方、開発中の構想、毎日のログなどを置く。一方の01_projectには、アプリのコード、Webサイト、デザインデータ、発信物など、実際に手を動かしてつくるものを置く。

この分離には、単なる整理以上の意味がある。

コードのリポジトリだけを見ても、「なぜこれをつくるのか」「いま何を優先するのか」は分からない。反対に、企画書や方針だけがあっても、動くプロダクトは生まれない。そこで、判断の根拠を持つ場所を「脳」、成果物を持つ場所を「実体」として分けた。

Claude Codeには、まず脳側の入口を読ませる。そこには全情報を書かず、「何について知りたければ、どこを見るか」という地図だけを置く。プロジェクトの作業に入ったら、実体側の各フォルダにある入口ファイルを読み、その部屋だけに集中する。

ひとつの巨大な指示書に全部を詰め込まないことも重要だった。入口は受付係に徹し、詳細は各部屋へ降ろす。こうすると、AIが毎回読む情報を絞りながら、必要なときだけ深くたどれる。

情報ごとに「正典」を1つだけ決める

フォルダを分けても、同じ情報が複数箇所にあれば、すぐに食い違う。そこで次に決めたのが正典マップだった。

正典とは、その情報について最後に信じる場所である。たとえば、目標は目標のファイル、プロジェクトの概要はプロジェクトページ、タスクはタスク管理ツール、作業の生ログはログフォルダ、デザインの共通ルールはデザインシステム、というように役割を固定する。

ここで大事なのは、保存先だけでなく書き込みポリシーも一緒に決めることだ。

どの情報はAIが確認なしで追記してよいか。どの情報は追加だけで上書きしてはいけないか。どの変更は本人の承認が必要か。正典の場所だけが決まっていても、更新ルールが曖昧だと、AIは安全のために毎回止まるか、逆に変えてはいけないものまで書き換えてしまう。

僕の環境では、日々の観測ログは自動追記できる。一方で、方針の変更や共有ルールの改定は、差分を提示して承認を取ってから反映する。一次情報は追加のみで残し、整理や要約は別の正典へ書く。

「どこに書くか」と「誰がどこまで書いてよいか」を一組で決めたことで、AIへの指示はかなり短くなった。

人が忘れる部分はフックに任せる

ルールは、守ろうと意識している間しか機能しない。毎回「ログを書いて」「構成が乱れていないか確認して」「バックアップして」と頼む運用は、いつか止まる。

そこで、忘れる前提の処理はフックや定期実行へ移した。

ひとつ目は、作業ログの自動記録である。セッション中の実装、判断、失敗、学びを一時的にため、区切りのよいタイミングやセッション終了時にログへ書き戻す。人間が日報を書くのではなく、AIがその日に変更されたものを読み、行動の記録をつくる。

二つ目は、ディレクトリ構成のドリフト検知だ。番号で並び順を固定しているフォルダに抜けや重複が出たとき、参照先が古くなったとき、入口の地図と実体がずれたときに検知する。整理を一度の大掃除にせず、崩れ始めた時点で気づけるようにした。

三つ目は、毎日のgitチェックポイントである。夜に自動で差分を保存し、ファイル移動や自動書き戻しを後から確認・復元できるようにする。ただし、機密性の高いファイルを検知した場合は保存を中止する。自動化は「何でも実行すること」ではなく、止まる条件まで含めて設計する必要がある。

この3つに共通するのは、人間の注意力を信用しすぎないことだ。大事な処理ほど、思い出したときにやるのではなく、作業の流れに埋め込む。

タスクの正典は秘書ツールに一本化した

以前は、会話の中で決まったこと、カレンダー、メモ、タスクリストに「やること」が散らばっていた。AIに相談すると優先順位は出るが、その結果が会話にしか残らない。翌日には、また一覧を見て決め直すことになる。

そこで、タスクの状態、期限、優先度を持つ唯一の場所として、自作のPWAを置いた。AIはそこを読み、「今日やる分」を決めて書き戻す。人間は決まったものを実行し、終わったら報告する。

ここでAIに任せているのは、タスクの実行ではなく選ぶ判断である。

タスクが多いときにつらいのは、作業量だけではない。「今日は何から始めるか」を毎朝決めるコストが大きい。固定で3件を選ぶのではなく、重い仕事が1件の日も、短い緊急対応が複数ある日も、その日の予定と目標から勝ち筋を決める。

思いつきの割り込みも禁止しない。まず記録し、緊急なら今日の計画を組み替え、そうでなければ正典へ戻す。AIとの会話をタスクリストの代わりにせず、会話で生まれた行動は必ずタスクの正典へ着地させる。

この一本化で変わったのは、管理画面の見た目より、会話が変わってもタスクが消えなくなったことだった。AIは記憶に頼らず、毎回同じ正典を読んで判断できる。

エージェントを「社員」として運用する

さらに、繰り返し発生する役割は、単発のプロンプトではなく社員として切り出している。

現在は、人格と記憶を持つ5名のエージェントを役割別に配置している。それぞれに担当、判断範囲、話し方、参照する資料、学びを書き戻す記憶がある。Discordには部門ごとの部屋を用意し、仕事の種類ごとに相談と進行を分ける。

ここで「人格」は飾りではない。誰に何を任せるかを人間が直感的に判断しやすくし、エージェント側には役割の境界を保たせるために使う。調査担当が最終決定まで進めない、実装担当が事業方針を勝手に変えない、といった分業の線が名前と役割に結びつく。

社員制度の中心は、作業後の成長ループにある。

エージェントが作業中に得た学びは、終了時に短く記憶へ追記する。どの技をどれだけ使ったかは機械的に記録する。作業中に見つかった摩擦やルールとの食い違いは、次のセッションや週次レビューで回収する。正典本文を自動で書き換えるのではなく、まず観測事実として追加し、人間がいる場で統合する。

これにより、同じエージェントへ次の仕事を頼んだとき、前回の失敗や判断基準を持ち越せる。毎回プロンプトを長くするのではなく、仕事をするたびに役割の中身が少しずつ育つ構成にしている。

一次情報から記事までを一本の流れにする

AIが扱う情報は、整理されたナレッジだけではない。むしろ価値の源は、まだ整理されていない一次情報にある。

僕の環境では、外部との会話メモをtalks、自分由来の音声メモ、文字起こし、思考ダンプ、制作から得た知見、元データなどをsourcesへ保存する。どちらも元本であり、追加のみで書き換えない。

元本をそのまま記事にするわけではない。まず、会話や記録から再利用できるインサイトを抽出する。次に、その内容が既存の方針、プロジェクト、知識のどこへ接続するかを決める。必要なら正典を更新し、行動が必要ならタスクにする。そのうえで、外に出せる内容だけを記事へ変換する。

流れにすると、次のようになる。

talks / sources → インサイト抽出 → 正典へ接続 → タスクや記事へ展開

一次情報と公開物の間に「正典へ接続する」工程を挟むのがポイントだ。記事だけを書いて終わると、発信には使えても自分の判断基準は育たない。反対に、内部ナレッジだけを整えても、外への価値提供につながらない。ひとつの元本から、内側の学習と外側の発信を両方つくる。

全体はひとつの循環になっている

ここまでの仕組みを並べると、フォルダ管理、タスク管理、自動化、AIエージェント、記事制作と、別々の道具に見える。

しかし実際には、すべて同じ循環の中にある。

一次情報と日々の作業がログに残る。ログから学びが抽出され、正典と社員の記憶が育つ。正典を読んだAIが次のタスクを選び、プロジェクトの実体を更新する。その結果がまたログと一次情報になる。外に出せる学びは記事へ変わる。

この循環ができると、AIとの会話が使い捨てにならない。今日の作業が明日の判断材料になり、個別の成果物だけでなく、環境そのものが少しずつ改善される。

もちろん、自動化を増やせばよいわけではない。正典が決まっていない状態で自動書き込みを始めると、誤った情報が速く増える。役割の境界が曖昧なまま社員を増やすと、同じ仕事を複数のエージェントが持つ。まず置き場所とルールがあり、その上に自動化と組織を載せる順番が大事だった。

最初は70点のフォルダでいい

同じ環境を最初から全部つくる必要はない。むしろ、最初から完成形を設計しようとすると、運用する前に疲れる。

順番は次の4段階で十分だと思う。

1. フォルダを分ける。判断の材料と成果物の置き場所を決める
2. ルールを決める。情報ごとの正典と書き込みポリシーを1つにする
3. 自動化する。何度も忘れた処理だけをフックや定期実行へ移す
4. 組織化する。繰り返す役割だけをエージェントやスキルとして分ける

最初のフォルダは70点でいい。使っていれば、探しにくい場所、重複する情報、毎回頼んでいる処理が見えてくる。それが次に直すべき場所である。

AI作業環境は、一度つくって完成する設定集ではない。仕事をしながら育てる運用そのものだ。高性能な道具を増やす前に、まず「この情報はどこへ置くのか」「何を正として読むのか」を決める。そこから始めると、AIはようやく、会話相手ではなく継続して働けるチームの一員になる。