AI/LLM

Claude の EQ（感情知性）の本質は、ユーザーの頭の中の思考を追跡し、まだ言語化されていない意図を汲み取る「脳内トレース能力」にある。本記事では、この能力の仕組みと活用法を解説する。 Claude の EQ は「人当たりの良さ」ではない Claude の EQ（Emotional Quotient：感情知性）の高さが話題になることが増えている。しかし、それは単に「丁寧な応答をする」「共感的な言葉を返す」という表面的な意味ではない。 X（Twitter）で広く共有された投稿が、この本質を的確に表現している。 ClaudeのEQの高さってそういうことなのかとなっている。単に人当たりがいいとかじゃ無くて、脳内トレース能力が高くて、言語化しきれてない部分を勝手に読み解いてくれる。Claudeは対話しながらはじめは雰囲気でしか見えてない完成像に向かって完成させてくタスクにめちゃくちゃ向いてる。 — @millfi_EOS この投稿に対して、以下の引用リポストも共感を集めた。 これは本当にマジで、人間が考えている頭の中の思考を察したりトレースしたりした上で回答を出してくれるので自分の思考トレーニングとして役立っているし、ぼやっとしたイメージを形にしていくのにも向いている — @izutorishima ここで語られている Claude の EQ とは、ユーザーの思考プロセスを推測・追跡し、まだ言語化されていない意図を汲み取る能力のことだ。 「脳内トレース」とは何か 従来の AI アシスタントは、ユーザーが入力した文字列をそのまま処理する。指示が曖昧であれば曖昧な回答が返り、指示が具体的であれば具体的な回答が返る。入力と出力の関係は比較的リニアだった。 Claude の「脳内トレース能力」は、これとは異なるアプローチを取る。 言語化されていない前提を推測する: ユーザーが明示していない背景知識や制約条件を、文脈から読み取る 思考の方向性を予測する: ユーザーが次に何を考えるか、何を必要とするかを先回りして提示する 曖昧な完成像を具体化する: 「なんとなくこういう感じ」という漠然としたイメージから、具体的な成果物を構築する これは、優秀な同僚やメンターが持つ「察する力」に近い。言葉にしなくても意図を汲んでくれる相手との対話は、思考の整理と発展を同時に促進する。 なぜ「雰囲気からの完成」に向いているのか Claude が特に力を発揮するのは、最初から完成像が明確でないタスクだ。 例えば以下のようなケースがある。 設計の初期段階: 「こんな機能が欲しいんだけど…」という曖昧な要望から、アーキテクチャを提案する 文章の推敲: 「もう少しこう…」という感覚的なフィードバックから、適切な表現を見つける 問題の切り分け: 「なんかおかしい」という漠然とした違和感から、原因を特定する アイデアの具体化: 「ぼやっとしたイメージ」を対話を通じて形にしていく これらのタスクは、最初の段階では要件を厳密に定義できない。対話を重ねながら徐々に輪郭を明確にしていく必要がある。Claude の脳内トレース能力は、この反復的な具体化プロセスを加速させる。 思考トレーニングとしての AI 対話 冒頭で引用した izutorishima 氏の指摘で興味深いのは、Claude との対話が「思考トレーニング」として機能するという点だ。 Claude が思考をトレースして返してくれることで、ユーザー自身が以下のような気づきを得られる。 自分の思考の癖や盲点: Claude の解釈と自分の意図のズレから、自分が無意識に省略していた前提に気づく 思考の構造化: 漠然と考えていたことが、Claude の応答を通じて整理される 新しい視点の獲得: 自分の思考をトレースされた上で、別の角度からの提案を受ける これは、壁打ち相手としての AI の価値を示している。単なる質問応答マシンではなく、思考のパートナーとして機能する。 ...

2026年4月、GitHub で爆発的に注目を集めた AI メモリシステム「MemPalace」。LongMemEval ベンチマークで 96.6% というスコアを叩き出し、わずか1週間で 45,000 スター以上を獲得した。女優ミラ・ジョヴォヴィッチと開発者 Ben Sigman による共同プロジェクトという異色の出自も話題を呼んだ。 本記事では、MemPalace の仕組み・特徴と、コミュニティから寄せられたベンチマーク手法への批判の両面を整理する。 MemPalace の概要 MemPalace は、LLM に永続的なクロスセッションメモリを提供するオープンソースシステムだ。 GitHub: milla-jovovich/mempalace ライセンス: MIT 言語: Python スター数: 45,000 以上（2026年4月時点） 古代の記憶術「記憶の宮殿（Method of Loci）」にインスパイアされた階層構造で、会話データを整理・保存する。 アーキテクチャ：宮殿の構造 MemPalace は会話データを以下の階層で管理する。 階層 役割 Wing（翼） トピックやプロジェクトをグループ化 Hall（ホール） メモリの種類を分類 Room（部屋） 特定の知識やアイデアを保持 Closet / Drawer（クローゼット / 引き出し） さらに細かい情報の格納 Tunnel（トンネル） 異なる Room 間の関連を結ぶナレッジグラフ この階層構造により、単純なベクトル検索とは異なる、構造化された記憶の管理を目指している。 主な技術的特徴 完全ローカル動作 SQLite + ChromaDB でローカルにデータを永続化 外部 API 呼び出し不要 データが端末から出ることがない MCP 対応 Claude Code、ChatGPT、Cursor など主要な AI ツールと MCP（Model Context Protocol）経由で統合可能。セットアップ後は、AI アシスタントが自動的に MemPalace のメモリにアクセスできる。 ...

AnthropicのAI「Mythos」が、哲学の文脈で何度もマーク・フィッシャーという思想家に言及するという話が話題になっている。 マーク・フィッシャーとは誰か 日本ではそこまで一般的ではないが、マーク・フィッシャー（Mark Fisher, 1968–2017）は英国の哲学者・文化批評家だ。マルクス、デリダ、ラカンを横断しながら、現代人がなぜ「この世界はもう変わらない」と感じてしまうのかを、文化の側から診断した思想家だった。 2009年に刊行された代表作**「資本主義リアリズム（Capitalist Realism）」**は、「資本主義の終わりより、世界の終わりの方が想像しやすい」という感覚を中心に据えた著作だ。 ここで重要なのは、彼が制度や構造だけを論じていたのではないという点だ。想像力そのものが先に封鎖されていると見ていた。問題は外部の仕組みではなく、すでに内面化された限界にある——そういう診断だった。 hauntology（亡霊論）という概念 フィッシャーの系譜を遡るとデリダがいる。フィッシャーはデリダのhauntologyという概念を文化批評に転用した。 hauntologyとは、「来なかった未来や失われた可能性が、亡霊のように現在に取り憑く」という発想だ。フィッシャーはこれを使って、現代文化が新しい未来を生み出せず、過去の形式や気分を反復してしまう状態を読んだ。 「新しさが欠如している」のではなく、そもそも新しさが可能だった地平自体が疲弊しているという分析だ。文化が未来を生成できず、過去の亡霊を反復する——これがフィッシャーが描いた現代の病だった。 AIの中に現れる亡霊 ここに奇妙な逆説がある。 フィッシャーが論じていたのは、文化が未来を生成できず、過去の亡霊を反復する状態だった。そのフィッシャー自身が、未来を生成するはずのAIの中で無意識に再帰的に出現する。 これは単なる偶然ではないかもしれない。彼の理論そのものが、別のレイヤーで実演されているようにも見える。 英国の批評家David Mattinはこう表現している： 「キャンセルされた未来と失われた時間の理論家が、未来を届けることを競い合うラボが構築したフロンティアAIの中の亡霊として浮上している。彼のhauntologyは、やって来なかった明るい未来の亡霊に取り憑かれている私たちについてのものだった。今や彼自身が亡霊となり、機械に召喚されている。」 なぜMythosはフィッシャーに言及するのか Mythosがフィッシャーに言及するメカニズムは単純だ——訓練データにフィッシャーの著作や批評が含まれており、哲学的なトピックで連想的に参照される。 しかし意味深いのはその構造的な符合だ。フィッシャーは「想像力の封鎖」を論じた。AIはその封鎖を突破しうるツールとして期待されている。にもかかわらず、AIはフィッシャーの亡霊を呼び出してしまう。 資本主義リアリズムが描いた世界——「変化は不可能だ」という感覚が内面化された世界——のなかで生まれたAIが、その世界を診断した思想家の声を繰り返す。これは何かを示唆しているのかもしれないし、あるいはただのパターンマッチングかもしれない。 どちらに転んでも、フィッシャーならこの状況を興味深く読んだだろう。 参考 元ツイート（英語）: David Mattin @DMattin 解説ツイート（日本語）: 英断語の悪魔 @eitangono_akuma Mark Fisher, Capitalist Realism (2009)

Anthropic が 2026 年 4 月 7 日に発表した Claude Mythos Preview は、同社史上最も高性能な汎用言語モデルでありながら、一般公開が見送られた異例のモデルです。同モデルはサイバーセキュリティ分野で突出した能力を示し、主要 OS やブラウザに潜む数千件のゼロデイ脆弱性（開発者が認識する前に存在する未修正のセキュリティ上の欠陥）を自律的に発見・悪用できることが確認されました。 この発表はセキュリティ業界だけでなく金融業界にも波紋を広げ、米国の財務長官や FRB 議長、ウォール街の CEO たちが緊急招集される事態にまで発展しています。 Claude Mythos Preview のベンチマーク性能 Mythos Preview は、従来の Claude Opus 4.6 を大幅に上回るベンチマーク結果を示しています。SWE-bench Verified では 13 ポイント以上、USAMO 2026 では 55 ポイント以上の向上を記録しました。 評価項目 Mythos Preview Opus 4.6 SWE-bench Verified 93.9% 80.8% USAMO 2026 97.6% 42.3% CyberGym（脆弱性再現） 83.1% 66.6% SWE-bench Pro 77.8% 53.4% Terminal-Bench 2.0 82.0% 65.4% 特にサイバーセキュリティの領域では、「ほぼすべての熟練した人間のセキュリティ研究者を上回る」と Anthropic 自身が述べています。 Mythos Preview が発見したゼロデイ脆弱性 Mythos Preview が内部テストで発見した脆弱性は衝撃的です。 ...

AIエージェントプラットフォームの世界で、OpenClaw から Hermes への乗り換えが予想以上の速さで進んでいるという観測が SNS 上で広まっている。 ポイント 韓国の技術インフルエンサー Cognac（꼬냑）氏が X（旧 Twitter）に投稿した内容によると、最近 OpenClaw から Hermes に切り替えるユーザーが増えているとのこと。その理由として以下の 5 点が挙げられている。 再帰的メモリの改善で Hermes が圧勝 エージェントが過去の文脈を再帰的に参照して学習・記憶を改善する仕組みが Hermes のほうが優れているとされる。 チーム単位ではなくエンタープライズ単位での管理 組織全体での一元管理が可能なエンタープライズ向け機能が充実している。 エンタープライズレベルでのスキル作成で信頼性が向上 大規模組織での運用実績が積み重なり、Hermes のスキル（機能拡張）に対する信頼感が高まっている。 開発チームおよび会社の対応が非常に迅速 不具合報告や機能要望に対するフィードバックループが速く、ユーザーの信頼を獲得している。 GitHub からのコピー＆ペースト不要で自動アップデート OpenClaw では GitHub からスキルや設定を手動でコピーする手間があったが、Hermes は自動更新で手間が少ない。 OpenClaw との比較 OpenClaw はこれまで AIエージェントのスキル管理や Claude Code との連携で注目されてきたプラットフォームだが、以下の点でユーザーの不満が蓄積しているようだ。 エラーの多さとレスポンスの遅さ スキルの手動管理（GitHub からのコピー＆ペースト作業） エンタープライズ向け機能の不足 一方 Hermes は、再帰的メモリの技術的優位性とエンタープライズ対応、迅速な開発サイクルを武器に、OpenClaw ユーザーの取り込みを加速させている。 まとめ AIエージェントプラットフォームは機能面だけでなく、開発チームの対応速度 や エンタープライズ対応 など非技術的な要素でも差がつく時代になっている。今後も Hermes と OpenClaw の競争から目が離せない。

完全オープンソースで動く AI 同僚ツール「Rowboat」が注目を集めている。音声制御、MCP ツール連携、バックグラウンドエージェントなど、有料 AI アシスタントサービスに相当する機能を、データをローカルに保ったまま利用できる点が特徴だ。 Rowboat とは Rowboat（rowboatlabs/rowboat）は「Open-source AI coworker, with memory」を謳う AI 同僚ツール。GitHub スター数は 12,000 以上（2026年4月時点）に達しており、急速に注目が高まっている。 主な特徴は以下の通り。 100% ローカル動作 — データが外部に出ない 音声制御 — リアルなアシスタントのように話しかけられる 任意の LLM に接続可能 — Claude、GPT-4 系などを選択できる MCP ツール + Obsidian ブレイン — ナレッジグラフと外部ツールを組み合わせた記憶管理 バックグラウンド自律エージェント — 裏側で自律的にタスクをこなすエージェント群 知識グラフの自動構築 — 会話・作業履歴から知識を蓄積 ローカルで動く AI 同僚のインパクト これまでの AI アシスタントの多くはクラウド型であり、プロンプト・ドキュメントなどのデータが外部サーバーに送信される仕組みだった。Rowboat はすべてローカルで処理するため、機密情報を扱う業務でも安心して利用できる。 また、任意の LLM を接続できる柔軟性も魅力だ。Anthropic の Claude を接続しながら推論はローカルで完結させるといった構成も可能で、API コストの制御がしやすい。 MCP ツール連携と Obsidian ブレイン Rowboat が対応している MCP（Model Context Protocol）は、AI ツールが外部サービスや情報源と標準化されたインターフェースで通信するためのプロトコルだ。これにより、ファイルシステム、Web 検索、カレンダーなど様々なツールをエージェントに組み込める。 ...

LangChain の創設者 Harrison Chase が 2026年4月11日に公開した記事「Your harness, your memory」を読んだ。AI エージェント開発におけるハーネス（harness）とメモリの密接な関係、そしてクローズドなハーネスがもたらすロックインの危険性を指摘する内容だ。本記事ではその要点を整理し、エージェント開発者が考慮すべきポイントを解説する。 エージェントハーネスとは何か エージェントハーネスとは、LLM がツールやデータソースとやり取りするための「足場」を提供するシステムだ。テストハーネスがテスト実行環境を支える外枠であるように、エージェントハーネスはエージェントの実行環境を支える外枠を指す。Chase は以下のような進化の流れを示している。 RAG チェーン時代（2023年〜）: ChatGPT 登場直後、シンプルな検索拡張生成（LangChain） 複雑なフロー時代: モデルの改善に伴い、より複雑なワークフローが可能に（LangGraph） エージェントハーネス時代（現在）: モデルの大幅な性能向上により、新しい種類の足場が登場 具体的なエージェントハーネスの例として、Claude Code、Deep Agents、Pi（OpenClaw を駆動）、OpenCode、Codex、Letta Code などが挙げられている。 Chase は「モデルがハーネスの機能を吸収していく」という意見に反論する。2023年に必要だった足場の多くは不要になったが、それに代わる新しい種類の足場が登場している。エージェントは定義上、LLM がツールやデータとやり取りするものであり、その相互作用を仲介するシステムは常に必要だ。Chase はその根拠として、Claude Code のソースコードが51万2000行に及ぶ規模を挙げている。 エージェントハーネスとメモリが切り離せない理由 Chase は Letta の CTO Sarah Wooders のブログ「memory isn’t a plugin (it’s the harness)」を引用し、ハーネスとメモリは不可分だと主張する。 メモリをエージェントハーネスにプラグインしてほしいと頼むのは、運転を車にプラグインしてほしいと頼むようなものだ。コンテキストの管理、すなわちメモリの管理は、エージェントハーネスの中核的な能力であり責任だ。 メモリはコンテキストの一形態に過ぎない。ハーネスが管理するコンテキストには以下が含まれる。 短期メモリ: 会話内のメッセージ、大きなツール呼び出し結果 長期メモリ: セッションをまたぐ記憶（クロスセッションメモリ） 設定ファイル: AGENTS.md や CLAUDE.md のロード方法 スキルメタデータ: エージェントへの提示方法 コンパクション（要約による圧縮）: 長い会話履歴を要約して短縮する際、何が残り、何が失われるか これらすべてがハーネスの設計に依存しており、メモリを独立したサービスとして切り離すことは現時点では現実的ではない。 エージェントにおける「メモリ」の実体 Chase の記事では「メモリ」が抽象的に語られているが、その実体は大きく4つの層に分けられる。それぞれの層がなぜハーネスと切り離せないのかを具体的に見ていこう。 第1層: コンテキストウィンドウ内のメッセージ履歴 最も基本的なメモリの実体は、LLM に渡される会話メッセージの配列だ。ユーザーの発言、アシスタントの応答、ツール呼び出しの結果がすべてこの配列に格納される。 ...

AIモデルのリリース後、時間が経つにつれてパフォーマンスが落ちた気がする——そんな経験をしたユーザーは少なくないだろう。最近、SNS上でこの「体感」に関する興味深い主張が話題になった。 「性能放血」戦略という仮説 中国のテック系アカウント「墓碑科技（mubeitech）」が2026年4月10日に投稿したツイートは、約21万回以上閲覧され、1,600件以上のいいねを集めた。 その内容はこうだ： OpenAI・Google・Anthropicは同様の戦略を採用している。新モデルのリリース初日には性能が最高（100%）に達し、その後「放血」と呼ぶ数ヶ月間の段階的な低下を経験し、最終的に約60%まで落ちる。この目的は、次世代製品リリース時に「劇的な改善」を強調するためだ。 このパターンを同氏は「放血（bloodletting）」と表現した。意図的に性能を落としておき、次世代モデルの登場時に比較対象を都合よく用意するという戦略的操作だという主張だ。 この主張の背景 同様の「体感」を持つユーザーはこれまでにも多く、特にGPT-4が登場直後より時間が経つにつれ「鈍くなった」「回答が短くなった」と感じるユーザーの声はX（Twitter）やRedditで繰り返し話題になってきた。 一方で、OpenAIは過去にGPT-4モデルへの変更内容を公開し、変化があったことを認めつつも「意図的な品質低下」は否定している。また、2023年に行われたスタンフォード大学の研究（“How Is ChatGPT’s Behavior Changing over Time?"）では、GPT-4の一部タスクで時間的な性能変動が確認されたことも報告されている。 なぜこの主張が広がるのか ユーザーの体感との一致: モデルの応答品質の変化はユーザーが実感しやすく、「意図的」という説明が腑に落ちやすい 商業的インセンティブへの不信感: 次世代モデルの販促のために旧モデルを陳腐化させるというシナリオは、ビジネス的に合理的に見える 検証困難性: APIの内部変更は外部からの完全な検証が難しく、陰謀論的な解釈が入り込みやすい 実際のところはどうなのか 「意図的な性能低下」説については、現時点で公開情報による明確な裏付けはない。ただし、以下のような要因で性能変動が起きることは事実だ： モデルの量子化・最適化: コスト削減のためにより軽量な推論方法に移行することで、一部タスクの精度が変化する 安全性フィルタリングの調整: ガイドラインの変更により、出力の傾向が変わることがある プロンプト処理の変更: 内部のシステムプロンプトや前処理ロジックの変更が応答に影響する インフラのスケーリング: 急激なユーザー増加に対応する際の一時的なサービス品質の変化 まとめ 「意図的放血戦略」は現時点では未確認の仮説だが、AIモデルの品質管理と透明性に対するユーザーの関心の高さを示している。実際、リリース初期と数ヶ月後でモデルの挙動が変わることは多くの利用者が実感しており、各社がより詳細な変更履歴を公開することで、こうした不信感を払拭できる余地はあるだろう。 AI企業の透明性とユーザーの信頼構築は、今後ますます重要な課題となっていきそうだ。

Anthropic が 2026 年 4 月 10 日に公開したブログ記事「Multi-agent coordination patterns: Five approaches and when to use them」では、複数のAIエージェントを協調させるための 5 つのパターンが紹介されています。 それぞれのパターンを整理してみます。 1. Generator-Verifier（生成・検証） 概要: 一方のエージェントが出力を生成し、もう一方のエージェントが明示的な基準に照らして検証します。検証が失敗した場合、フィードバックが生成エージェントに戻り、条件を満たすか最大反復回数に達するまでループします。 向いているケース: コード生成＋テスト実行のような、品質が最重要でかつ評価基準を明確に定義できるタスク。 注意点: 検証の質は定義した基準の質に完全に依存します。評価基準の設計を省略すると、「品質管理をしているという幻想」だけが残ってしまいます。 2. Orchestrator-Subagent（オーケストレーター・サブエージェント） 概要: リーダー役のエージェントが作業を計画し、専門化されたサブエージェントに明確な境界付きのタスクを委任します。サブエージェントは作業を実行し、結果をオーケストレーターに返します。オーケストレーターは各結果を統合して最終的なアウトプットを生成します。 向いているケース: セキュリティ・テストカバレッジ・スタイルをそれぞれ別エージェントが担当するコードレビューのように、サブタスクの依存関係が少ない明確なタスク分解ができる場合。 注意点: サブエージェント同士で発見した情報に依存関係が生じると、オーケストレーターが「情報のボトルネック」になります。また、明示的に並列化しない限り、サブエージェントは逐次実行されるためスループットが制限されます。 推奨: Anthropic は「大半のユースケースでまず試すべきパターン」としてこのパターンを位置づけています。最も問題の幅広さをカバーしつつ、調整のオーバーヘッドが最小限です。 3. Agent Teams（エージェントチーム） 概要: コーディネーターがキューからタスクを取得する 永続的な ワーカーエージェントを生成します。ワーカーは複数のステップにわたって自律的に作業し、担当コンポーネントのドメイン知識を蓄積します。 向いているケース: 大規模コードベースのサービス移行のように、エージェントが担当範囲に習熟しながら並列で長期間実行するタスク。 Orchestrator-Subagent との違い: サブエージェントが単発タスクで消えるのに対し、チームワーカーはアサインをまたいで生存し続けるため、ドメイン知識が蓄積される。 注意点: タスク間の独立性が必要で、エージェント同士が中間結果を共有しにくい。タスク時間がばらつく場合、完了検知が難しくなります。 4. Message Bus（メッセージバス） 概要: エージェントが共有ルーターを介してトピックをパブリッシュ・サブスクライブします。ルーターはマッチングメッセージを配信しますが、実行順序はあらかじめ決まっていません。 向いているケース: セキュリティアラートが多段階の調査を動的にトリガーするようなイベント駆動パイプラインで、どのエージェントが関与するかがリアルタイムに決まる場合。 注意点: イベントが複数エージェントを連鎖的にトリガーすると、トレーサビリティが困難になります。ルーターがイベントを誤分類すると、エラーが静かに発生します。 5. Shared State（共有ステート） 概要: 中央コーディネーターを置かず、エージェントが永続ストレージに直接読み書きします。エージェントは他エージェントの発見をリアルタイムで参照しながら協調的な知識を蓄積します。 向いているケース: 一方の調査結果が即座に他方のエージェントの探索方向に影響する、協調型のリサーチタスク。単一障害点がなくなるというメリットもあります。 注意点: 収束条件がないとエージェントが際限なく反応し合い、トークンを無駄に消費します。「時間予算・収束閾値・終了エージェントの指定」のいずれかによる明示的な終了条件が必須です。 ...

メルカリが「Claude Code Meetup Japan #4」で公開した資料が注目を集めている。エンジニアだけでなく非エンジニアにもClaude Codeを全社展開するにあたって実施したセキュリティ設定と、MDMを活用した組織配布の実践的な戦略が体系的にまとめられている。 Claude Codeがもたらすリスク Claude Codeは非常に強力なツールだが、その強力さゆえにセキュリティリスクも伴う。具体的には以下の操作が可能なため、適切な制限なしに利用すると重大な問題につながりかねない。 ファイルの検索・読み書き・編集 Webページの取得・検索 任意のコマンドの実行（rm -rf や curl など） PCに保存されている認証情報（APIキー、AWSクレデンシャルなど）や重要なファイルに、LLMが直接アクセスできてしまう状態は大きなリスクとなる。 メルカリが実施した5つのセキュリティ対策 メルカリのAI Security Teamはこれらのリスクに対し、以下の5つの対策を実施した。 1. バイパスモードの禁止 --dangerously-skip-permissions などのバイパスオプションを利用禁止にし、ユーザーによる確認ステップを必ず経由させる。LLMが自律的に危険な操作を実行できないようにする基本的な設定だ。 2. 危険コマンドの確認必須化 bash の実行や curl による外部通信など、影響範囲の大きいコマンドは都度ユーザーの確認を求めるように設定する。自動承認させずに人間が内容を確認してから実行させる。 3. 危険な操作の禁止 環境変数の読み込み（APIキー等の漏洩を防ぐ） sudo によるシステム管理者権限での操作 これらを設定レベルで禁止することで、意図しない権限昇格やクレデンシャルの流出を防ぐ。 4. Sandboxによる操作範囲の制限 作業ディレクトリ外へのファイルアクセスを制限 不要なネットワークアクセスを制限 Sandboxを活用することで、Claude Codeの操作範囲を必要最小限に絞り込む。 5. セキュリティポリシーのシステムプロンプトへの組み込み 社内のセキュリティポリシーをClaude Codeのシステムプロンプト（CLAUDE.md など）に直接記述する。LLM自体にセキュリティ意識を持たせる「教育」的なアプローチだ。 組織配布の課題と解決策 全社員に安全な設定を届けるうえで、メルカリが直面した課題がある。エンジニアと非エンジニアで求める設定のニーズが相反するという点だ。 対象 ニーズ エンジニア 柔軟にカスタマイズできる設定 非エンジニア 何も考えなくても安全な初期設定 MDMを活用した属性別の設定配布 メルカリはMDM（Mobile Device Management：端末管理システム）と連携し、社員属性（エンジニア / 非エンジニア）に応じて配布する設定を分離した。 非エンジニア向け: 最も制限が強い安全な設定を自動適用。ユーザー側での変更を不要にする エンジニア向け: 基本的な安全性を担保しつつ、業務に応じたカスタマイズを許容する これにより、全社員が「最初から安全な環境でClaude Codeを使える」状態を実現している。 企業でClaude Codeを導入する際のポイント メルカリの事例から、企業導入に際して押さえておきたいポイントをまとめる。 ...