AIエージェント用ワークスペース設計 — 個人環境と共有環境を分ける

AIエージェントを業務に入れるとは、自律的にファイルを読み・実行するプログラムを組織に迎え入れることです。そのとき最初に決めるべきは「どのモデルを使うか」ではなく、エージェントに会社のどこまでを触らせるか、つまりワークスペース（作業境界）の設計です。

AIエージェントの実行環境としての「ワークスペース」とは

ここで言うワークスペースとは、エージェントが動く区切られた実行環境のことです。1つのワークスペースの中でエージェントは自由に働き、外には出られない。この境界が決めるのは次の3つです。

• 見える範囲 — どのファイル・データに到達できるか
• できること — どのツールを実行でき、どこへ通信できるか
• 記録の単位 — 「この部屋で起きたこと」として監査・巻き戻しの単位になる

権限を細かく設定する前に、まず境界で大きく区切る。先に境界を設計しておくと、個別の権限設定にミスがあっても影響が部屋の中に収まりやすく、後続の権限設計もシンプルになります。プロンプトインジェクション対策の観点でも、この境界が被害範囲の上限になります（プロンプトインジェクションを前提にしたAI実行環境の考え方）。

区切りの3つの軸

軸1: 人 — 誰の環境か

最も基本の区切りです。社員ごとにワークスペースを分ければ、「誰がやったか」が環境の単位で明確になり、責任と記録が一致します。共用アカウント・共用環境は、便利な反面この対応を壊すため、原則は1人1部屋以上です。

軸2: 仕事 — 何のための環境か

同じ人でも、プロジェクトAとプロジェクトBで触るものは違います。仕事単位で部屋を分けると、情報の混在による誤参照が起きにくくなります。エージェントが「隣の仕事の情報」をうっかり読む、という類の事故です。すべての仕事を分けるとコストが上がるため、情報の混在が問題になる仕事（顧客別の業務、ライセンス的に分けたいコード等）から分けるのが現実的です。

軸3: 機密度 — 何を扱う環境か

最も重要な区切りです。機密データを扱う部屋と、外部（クラウドAI）に接続できる部屋を同じにしない。この1つの区切りだけで、「AIに機密を入れてしまった」という典型的な誤投入事故を大きく減らせます（クラウドLLMとローカルLLMの使い分け）。

実務の出発点としては、人×機密度の2軸、つまり「社員ごとに、通常の部屋と機密用の部屋」から始め、必要に応じて仕事軸を足すのが扱いやすい構成です。

個人環境と共有環境

区切る話の対になるのが、共有の設計です。チーム開発では、共有リポジトリ・共有の知識・共通ツールが要ります。

設計の原則は、働く場所は個人に、成果物は共有にです。エージェントは個人の部屋で働き、成果はリポジトリへ・知識は承認を経て共有へ、という一方向の流れにすると、「誰の作業か」の明確さと「組織で積み上がる」の両立ができます。機密度の高い知識は機密側の部屋にだけ配る、という機密軸との掛け合わせも、この構造の上なら設計できます。

設計を確認する5つの観点

ワークスペース設計（または製品の設計）を評価するときの確認観点です。

1. 部屋の外のデータへの到達は、何で制限されているか（個別の設定の積み重ねか、境界の構造か）
2. 機密の部屋と外部接続の部屋は分かれているか
3. 部屋は使い捨てられるか（壊れたとき・汚れたとき、捨てて配り直せるか）
4. 部屋単位の記録が残るか（誰の・どの部屋で・何が起きたか）
5. 部屋の発行・回収は運用に耐える手間か（1部屋作るのに半日かかる設計は定着しない）

まとめ

• ワークスペースは「エージェントが触れてよい範囲」を構造で定義する境界。権限設定より先に区切りを設計する
• 軸は人・仕事・機密度。実務は人×機密度（通常の部屋＋機密の部屋）から始める
• 働く場所は個人に、成果物・知識は共有に。一方向の流れで両立する
• 良い設計は「構造で越えられない・使い捨てられる・記録が残る・運用が軽い」

Hoko（矛）は、このワークスペース設計を箱として提供するAIエージェント実行アプライアンスです。部屋は、機密用（外部への経路なし・ローカルLLMのみ）とクラウドAI接続用の2つのルームとして発行されます。