セミナーレポート#02 全社でClaude Code & Codexを使うためのセキュリティ戦略【Claude Code & Codex 実装現場ノート】

前回、AIサービスを「動いた」から「回る」に進める出発点として、境界の設計を扱った。本記事ではその次にやってくる現実的な壁、組織で回すための設計に踏み込む。

個人で使うClaudeと、全社で使うClaudeは、別物だ。配布範囲を広げた瞬間、シャドーIT、機密データの流出、コスト爆発、定着しない、という4つのリスクが同時に立ち上がる。これらをガイドラインで「気をつけて」と注意喚起しても、ほぼ意味がない。必要なのは、技術と環境で構造的に止める仕組みだ。

本記事では、その仕組みを「ナレッジ管理の3層」と「セキュリティの4レイヤー」、そして「APIキーの正しい持ち方」という3つの設計図で示す。

「自分のClaude」と「全社のClaude」は別物

まず、なぜ全社展開で前提が変わるのかを整理しておく。配布範囲を広げた瞬間、4つのリスクが構造的に立ち上がる。

• シャドーIT化──個人が会社メールでアカウントを作る。気づいたら管理外
• 機密データの流出──プロンプトに貼る情報の線引きが曖昧。APIキーが平文
• コスト爆発──誰がどれだけ使っているか見えない。月末請求書で初めて気づく
• 定着しない──配って終わり。1ヶ月後、使うのは導入推進者だけ

そしてもう一つ重要なのは、AIエージェントは「考える」「答える」だけでなく、「実行する」という事実だ。チャットで答えを返すだけなら、間違っても「答えが違う」で済む。だが、ファイルを書き換える、APIを叩く、メールを送る - 実行する瞬間、取り返しがつかない可能性が生まれる。

間接プロンプトインジェクションを前提に、実行できることを構造で絞らなければならない。これが、全社展開の設計の出発点になる。

ナレッジを組織で蓄積する3層構造

全社展開の前に、まず「次の人が一発で動ける」状態を作る必要がある。AIを使えば使うほど、個人の中にナレッジが溜まり、それが組織の財産にならなければ、退職と共に蒸発する。

ナレッジを組織で蓄積するには、3層構造で考える。

CLAUDE.md / DESIGN.mdはプロジェクトのルートに置く。コードベースの読み方、命名規則、避けるべき罠を一枚にまとめる。新しいAIセッションが立ち上がった瞬間に読まれる「最初の手紙」だ。

skills/は、ドキュメント作成、SQL作法、レビュー手順といった再利用可能なナレッジを領域ごとにフォルダ化し、トリガーで自動発動する仕組みだ。スキルのデグレ対策として、入力例＋期待出力＋チェックリストを同梱し、月1回の回帰テストをかける。

NotebookLM × 社内Wikiは、議事録、提案書、過去案件を集約して横断検索の窓にする。Claude側からはツールとして問い合わせる。「会社の頭脳」を、退職と共に失わない設計だ。

そしてもう一つ、ナレッジ層の上で重要なのがAIの使い分けである。本流の頭脳はClaude (Opus / Sonnet 4.7)、実装はCodex、マルチモーダルはGemini、ナレッジ窓口はNotebookLM、事実調査はPerplexity / Felo。「全部Claude」も「全部GPT」も、もったいない。役割で組むアンサンブルが、2026年現在の現場最適解になっている。

セキュリティ4レイヤーの全景

ナレッジの土台が整ったら、次はセキュリティの4レイヤーだ。これは「気をつけて」と現場に丸投げするのではなく、環境で構造的に止めるための設計図である。

レイヤー①アクセス制御は、技術で「誰が、どこから、何を使えるか」を固定する層だ。会社ドメインを管理コンソールでクレームし、シャドーテナントを構造的に防ぐ。SSOを必須化してMFAをIdP側で一元管理。Oktaグループへのアサインで自動的にConsoleアカウントが発行され、退職時はOkta無効化と同時にAnthropic側のアクセスも失われる。

レイヤー②ガードレールは、間接プロンプトインジェクションで誘導される破壊的コマンド、外部送信、未承認MCPを実行不能にする層だ。Managed Settingsを書き換え不可な形でMDM配布し、設定はGitHubで履歴管理する。盗難時の影響を最小化するため、セッション保持期間も業務に支障ない範囲で短くする。

レイヤー③コスト最適化は、Claude CodeをConsole従量で運用し、使わない人に課金しない構造を作る。チャットはClaude、業務オートメーションはClaude Codeと使い分け、OpenTelemetryで「誰が、何トークン、どのモデルで使ったか」を個人別・部署別に可視化する。

レイヤー④組織展開は、配って終わりにしない設計だ。熟練度をLv0（未利用）からLv4（他者支援・推進）までの段階に分け、レベルごとに装備パッケージを変える。勉強会、ガイドライン、理解度テスト、段階的ロールアウトを、非エンジニアでも分かるように設計する。

APIキーの正しい持ち方 - 1Password CLIでメモリ上にだけ置く

事前アンケートで最も多かった質問が、「SaaS連携APIキーの保管」だった。ここはレイヤー②の補強として、独立して扱うべき重要なトピックだ。

まず、絶対にやってはいけない持ち方を整理しておく。

• .env / .zshrc / .bashrc に平文で書く
• Slack や Notion にキーを貼り付ける
• チャット入力欄に秘密情報を貼る
• Git に commit する（履歴は復元される）
• 退職メンバーのキーをそのまま放置

これらは「気をつける」では防げない。一度どこかに書かれた瞬間、ディスクに痕跡が残り、回収できない。

正しい持ち方は、「キーは存在するが、誰のディスクにも書かれていない」状態を運用上の標準にすることだ。

具体的には、mcp.json の中に書くのはキー本体ではなく、参照だけにする。

"API_KEY": "op://Vault/Secret/credential"

そして1Password CLI（op）でメモリ上だけで取り扱う。Touch IDで認証し、解錠タイマーで自動的に再ロックする。MDM側では、平文残存を定期スキャンして検知する仕組みを併用する。

この設計が定着すると、退職時にもキーが個人ディスクに残らないため、回収漏れによる事故が構造的に起きなくなる。地味だが、レイヤー②と並んでもっとも実効的な防御線になる。

情シス・経営者の6つの不安に、まっすぐ答える

ここまでの設計を整えても、実際の社内合意には情シスと経営層の不安を解消する必要がある。事前アンケートで頻出した6つの問いに、対応する打ち手をまとめておく。

最後の問いへの答えがこの記事のすべてを集約している。AIを全社で安全に回すための技術と仕組みは、2026年現在、ほぼ揃っている。MCPトンネルやSelf-hostサンドボックスといった選択肢が整い、自社ファイアウォール内でManaged Agentsを動かすことすら現実的になった。

残る課題は、これらをどう組織として設計し、運用するか。技術ではなく、合意形成と意思決定のスピードが、AI実装の競争力を決める時代に入っている。

ここまで、ナレッジの3層、セキュリティの4レイヤー、APIキーの正しい持ち方、そして情シスと経営者の不安への回答を扱ってきた。これらは個別の打ち手ではなく、互いに支え合う一つのアーキテクチャだ。どれか一つが欠けると、他のすべてが揺らぐ。

次回 #03「サービス化と『AIヴァンパイア』対策 - 持続可能な実装」では、ここまで整えてきた組織内のAIを、社外サービスとして出す段階に進む。Codex App Server時代の公開設計、「動くもの」がもう優位ではない時代の価値創出、そしてシリコンバレーで広がる「AIヴァンパイア」というキーワードが示す、AI時代の働き方と運用設計を扱う。

参考

• Anthropic「Claude for Enterprise」── Enterprise契約とゼロデータリテンション設定の公式情報。
  https://www.anthropic.com/enterprise
• Anthropic「Claude Code Managed Settings」── MDM配布によるガードレール設計の公式ドキュメント。
  https://docs.claude.com/
• 1Password「1Password CLI Documentation」── APIキーをメモリ上だけで取り扱う運用の公式ガイド。
  https://developer.1password.com/docs/cli/
• Model Context Protocol「MCP Specification」── ツール接続の標準仕様。
  https://modelcontextprotocol.io/