AI の名前に刻まれた「情報理論の父」— Claude Shannon が LLM の数学的基盤を作った @finalvent 氏が X で投稿した、Anthropic の AI「Claude」の名前の由来に関するポストが注目を集めています。 Claudeって、Claude Shannonに因んでるのか。知らなかった。 この一見シンプルな気づきは、現代の AI 技術と 78 年前の数学理論をつなぐ深い糸を浮かび上がらせます。Anthropic がなぜ自社の AI に「Claude」と名付けたのか — その理由を理解するには、Claude Elwood Shannon（1916-2001）が何を成し遂げたのかを知る必要があります。 Claude Shannon とは誰か 「情報の時代」を切り拓いた数学者 Claude Elwood Shannon は、1916 年 4 月 30 日、アメリカ・ミシガン州ペトスキーに生まれました。ミシガン大学で数学と電気工学の二重学位を取得した後、MIT の修士課程で書いた論文が、すでに歴史的な業績でした。 1937 年の修士論文 — 「A Symbolic Analysis of Relay and Switching Circuits」— は、ブール代数（真/偽の論理演算）を電気回路のスイッチに対応させるという発想を初めて体系化しました。この論文により、複雑な論理をスイッチの ON/OFF の組み合わせで実現できることが数学的に証明され、デジタルコンピュータの設計基盤が確立されました。 この修士論文は「20 世紀で最も重要な修士論文」と呼ばれることがあります。私たちが毎日使うスマートフォン、PC、サーバー — すべてのデジタル機器は、Shannon が 21 歳で示した原理の上に成り立っています。 ベル研究所と MIT Shannon は 1941 年から 1972 年までベル研究所（Bell Labs）に在籍しました。当時のベル研究所は、トランジスタの発明（1947 年）、UNIX オペレーティングシステム、C 言語など、現代のコンピューティングの基盤技術を次々に生み出した「イノベーションの殿堂」です。 ...

Amazon Bedrock が OpenAI API 互換を提供開始 — Mantle 推論エンジンが「モデルの交換可能性」を実現する @publickey が X で投稿した、Amazon Bedrock の OpenAI API 互換機能に関するブログ記事が話題を呼んでいます。 ブログ書きました： 「Amazon Bedrock」でOpenAI API互換を提供開始。オープンウェイトな基盤モデルでOpenAI SDKが利用可能に Publickey の元記事によると、AWS は Amazon Bedrock の Mantle 推論エンジンで OpenAI API 互換機能の提供を開始しました。これにより、開発者は使い慣れた OpenAI SDK をそのまま Amazon Bedrock 上で利用できるようになります。 この動きは単なる「API の互換性」にとどまらず、AI 業界の構造を変える可能性を持っています。本記事では、Mantle 推論エンジンの技術的な仕組みと、この互換性がもたらす業界への影響を掘り下げます。 Mantle 推論エンジンとは何か 分散推論の基盤 Mantle は、Amazon Bedrock のために構築された大規模モデル向け分散推論エンジンです。単なる API ラッパーではなく、以下の機能を内包する本格的な推論インフラです。 機能 説明 サーバーレス推論 容量管理を自動化し、デフォルトのクォータを引き上げ OpenAI API 互換 Chat Completions API / Responses API をネイティブサポート ステートフル会話管理 会話履歴をサーバー側で保持（Responses API） 非同期推論 長時間実行ワークロードのバックグラウンド処理 ストリーミング リアルタイムのレスポンス生成に対応 ゼロオペレーターアクセス NitroTPM による暗号学的な実行環境保証 セキュリティ設計 Mantle のセキュリティ設計は注目に値します。EC2 インスタンス証明（Instance Attestation）機能を活用し、顧客データ処理のための硬化された不変のコンピュート環境を構成しています。Nitro Trusted Platform Module（NitroTPM）による暗号署名付き証明測定で、モデルの重みと推論オペレーションを保護します。 ...

AnimaWorks — 「AIだけの会社組織」を作る日本発フレームワークの設計思想 りょうま(@ryoma_nakajima)氏のポストで紹介された「AnimaWorks」が注目を集めています。 日本人が開発している「AIだけで作る会社組織」フレームワークを試してみる。AIに性格を指定するところから始まるのが近未来感すごすぎて好き — りょうま(@ryoma_nakajima) 72,000超の表示、447ブックマークという反響は、「AIエージェントに組織を作らせる」というアイデアへの強い関心を示しています。元になったげれげれ(@medmuspg)氏のポストでは、OpenClawとの違いを「1人の優秀なAI秘書」と「AIだけの会社組織」という対比で説明しています。 本記事では AnimaWorks の設計思想を掘り下げ、マルチエージェントフレームワークの現在地を整理します。 AnimaWorks とは何か AnimaWorks は「Organization-as-Code」を標榜する、自律型AIエージェントチームのためのオープンソースフレームワークです。Apache License 2.0で公開されており、10,600行以上のPythonコードで構成されています。 コアの思想は明快です。 “Imperfect individuals collaborating through structure outperform any single omniscient actor."（不完全な個体が構造を通じて協力すれば、単一の全知の存在を凌駕する） 項目 内容 開発者 xuiltul（日本人開発者） 言語 Python（10,600行以上） ライセンス Apache License 2.0 対応モデル Claude, GPT-4o, Gemini, Mistral, Ollama 等 実行モード 4種（Claude Agent SDK / Codex SDK / LiteLLM / Basic） UI Webダッシュボード + 3Dワークスペース + 音声チャット OpenClaw との決定的な違い OpenClaw と AnimaWorks は同じ「AIエージェント」カテゴリに分類されますが、設計思想が根本的に異なります。 観点 OpenClaw AnimaWorks 設計思想 1人の優秀なAI秘書 AIだけの会社組織 エージェント数 基本は1体（拡張でマルチ可） 最初からマルチエージェント前提 関係性 ユーザーとエージェントの1対1 上司・部下の階層構造 記憶 コンテキストウィンドウ依存 神経科学に着想を得た永続記憶 通信 ユーザーへの応答 エージェント間の非同期メッセージング カプセル化 なし（透過的） 各エージェントの内部は他から不可視 開発元 Peter Steinberger（オーストリア、現OpenAI） xuiltul（日本） この違いは単なる機能差ではなく、組織論に基づく設計かどうかの差です。AnimaWorks は「不完全な個体の協力」を前提に設計されており、現実の企業組織と同じく、情報の非対称性やコミュニケーションコストを意図的に組み込んでいます。 ...

Claude Code / MCP を安全に使うための実践ガイド — settings.json の多層防御と deny の落とし穴 セキュリティ研究者のyousukezan氏（バグバウンティプログラムでランク1位受賞歴あり）が紹介した Zenn 記事「Claude Code / MCP を安全に使うための実践ガイド」が注目を集めています。165いいね、161ブックマークという反響は、Claude Code のセキュリティ設定に対する実務者の強い関心を示しています。 本記事では元記事の内容を掘り下げつつ、公式ドキュメントや GitHub Issues の情報を加えて、実務で本当に機能するセキュリティ設定を整理します。 背景 — 8桁後半の被害事例 この記事が書かれた背景には、AI コーディングツール経由で Google Ads の MCC が乗っ取られ、8桁後半の被害が発生した事例があります。報告された4つの攻撃ベクターは全て Claude Code / MCP の利用シーンで再現可能です。 攻撃ベクター Claude Code での該当リスク 間接プロンプトインジェクション Webページに埋め込まれた隠し指示をAIが実行 プロンプトサプライチェーン攻撃 外部から取得した CLAUDE.md / settings.json / .mcp.json の改ざん MCP権限悪用（Tool Poisoning） 許可済みMCPツールの悪意ある利用 クレデンシャルリーク トークンやAPIキーのログ・git履歴への残存 最も重要な3つの設定 元記事が推奨する最小限の設定は3つです。 1. bypassPermissions モードの無効化 1 2 3 4 5 { "permissions": { "disableBypassPermissionsMode": "disable" } } --dangerously-skip-permissions フラグは全ての承認プロンプトをスキップします。公式ドキュメントによると、このモードではClaude がファイルの削除、破壊的なコマンドの実行、不可逆な変更を承認なしで行えます。disableBypassPermissionsMode: "disable" で組織全体でこのモードを禁止できます。 ...

Claude Code サンドボックス完全解説 — chroot ではない、カーネルレベル隔離の仕組みと実践設定 「Claude Code のサンドボックスって、要するに chroot でしょ？」という誤解をよく耳にします。答えは明確にノーです。Claude Code のサンドボックスは chroot とは次元の異なるカーネルレベルの隔離機構で、ファイルシステムとネットワークの2層を OS プリミティブで強制します。 Anthropic のエンジニアリングブログによると、サンドボックスにより承認プロンプトが84%削減されました。セキュリティと生産性を両立する仕組みの全貌を、技術的な背景から実践設定まで解説します。 chroot との決定的な違い まず「chroot で十分か」という疑問に答えます。結論から言えば、chroot はセキュリティ対策として設計されていません。 隔離技術の比較 Practical CTF の解説を基に、主要な隔離技術を比較します。 技術 制限対象 脱出の容易さ 設計目的 chroot ファイルシステムのパス解決のみ 容易（root 権限で即脱出） 組織的なツール（セキュリティ目的ではない） seccomp システムコール 中程度（許可リストの漏れを突く） セキュリティ機構 namespaces プロセス、ネットワーク、マウント 困難（適切設定時） コンテナ隔離 Seatbelt ファイル、ネットワーク、IPC、プロセス 困難（カーネルレベル強制） アプリケーション隔離 chroot の脱出方法 chroot がセキュリティ対策に不十分な理由を具体的に示します。 カレントディレクトリ攻撃: chroot 実行時にカレントディレクトリが jail 外にあれば、相対パスで脱出可能 二重 chroot: 別の chroot を実行して前の制限を上書き ファイルディスクリプタ: jail 外で開かれた fd を経由してアクセス openat syscall: ディレクトリ fd を使って jail 外のファイルを操作 つまり chroot は「ルートディレクトリの表示を変えるだけ」であり、ネットワーク制限もシステムコール制限もありません。AI エージェントのサンドボックスとしては全く不十分です。 ...

Claude Code に「目」を与える — ローカル VLM で画像・動画をコンテキスト消費ゼロで理解させる @ShadeLurk 氏が X で公開した記事が注目を集めています。 Claude Code に「目」を作る — コンテキストを 1 トークンも使わずに動画を理解させる方法 Claude Code で画像や動画を扱うと、1 枚あたり数千トークンがコンテキストから消えます。ローカル VLM（Qwen3-VL 等）を MCP サーバー経由で接続し、画像処理をオフロードすることで、Claude Code のコンテキストを一切消費せずにビジュアル情報を扱う手法が提案されています。本記事では、この問題の構造と解決アプローチを技術的に解説します。 問題 — 画像 1 枚で数千トークンが消える Claude のビジョン処理とトークン消費 Claude API でのビジョン処理は、画像をトークンに変換してコンテキストウィンドウに載せる仕組みです。Anthropic の公式ドキュメントによると、トークン消費量は以下の式で算出されます。 tokens = (width px × height px) / 750 画像サイズ トークン数 1,000 枚あたりのコスト 200x200 px（0.04 MP） 約 54 約 $0.16 1000x1000 px（1 MP） 約 1,334 約 $4.00 1092x1092 px（1.19 MP） 約 1,590 約 $4.80 1 枚の高解像度スクリーンショットで 約 1,600 トークンが消費されます。Claude Code のコンテキストウィンドウは約 200,000 トークンですが、システムプロンプト・CLAUDE.md・会話履歴・MCP ツール定義などが既に占有しているため、実質的に使える容量は限られています。 ...

dotenvx で暗号化、1Password CLI で注入 — .env 平文ゼロのローカル開発環境を構築する @higa_toshiki 氏のポストが、ローカル開発で .env の平文を排除する実践的な手法を紹介しています（いいね 217、ブックマーク 255）。 ローカルに.envの平文を置きたくないけど、ローカルで開発したいこともあるので、 dotenvxで.envを暗号化 1 password cli で key を注入する を使ってます。 （元木さんの言うように「秘密情報の平文はクラウドに置こう」に則る形） 引用元の @swarm_ai_cloud 氏のポストでは、AI CLI の .env 読み込み防止機能への疑問が呈されています。 AI のCLIには.env読まない仕様があるって？そんなん信用できるか？AI CLIはバージョンが上がればバグが混入し弾くファイル設定していても普通に読んだりするし Claude Code が .env ファイルを自動的に読み込むことが確認されている今、「deny ルールで防ぐ」だけでは不十分という指摘は的を射ています。本記事では、higa 氏が紹介する2つのツール — dotenvx と 1Password CLI — の仕組みと実践的なセットアップ手順を解説します。 2つのアプローチの組み合わせ higa 氏のワークフローは、2つの異なるアプローチを組み合わせています。 ツール アプローチ 何を守るか dotenvx .env ファイル自体を暗号化 ファイルを読まれても平文が漏れない 1Password CLI クラウド Vault からランタイム注入 そもそもファイルにシークレットを置かない [dotenvx のアプローチ] .env（暗号化済み）→ dotenvx run → 復号してプロセスに注入 → .env.keys（秘密鍵）が必要 → Git にコミット可能 [1Password CLI のアプローチ] 1Password Vault（クラウド）→ op run → プロセスに注入 → Touch ID / マスターパスワードで認証 → ディスクに平文が一切残らない 両者は排他的ではなく、用途に応じて使い分けるのが現実的です。 ...

dotenvx・lkr・aws-vault・1Password CLI — .env 代替ツール4種の選び方とベストプラクティス AI エージェントが .env ファイルを読み取るリスクが現実のものとなり、平文の .env を代替するツールが続々と登場しています。本シリーズでは aws-vault、lkr、dotenvx + 1Password CLI をそれぞれ解説してきました。 しかし「結局どれを使えばいいのか」という疑問が残ります。本記事では、4つのツールの守備範囲・強み・限界を比較し、チーム構成や開発環境に応じた選択指針を提示します。 4ツールの守備範囲 最も重要な違いは管理対象の範囲です。 ツール 管理対象 DB接続 SaaS キー LLM API キー AWS 認証 aws-vault AWS 認証情報のみ - - - 対応 lkr LLM API キー（8社） - - 対応 - dotenvx .env に書ける全て 対応 対応 対応 対応 1Password CLI 全種類 対応 対応 対応 対応 aws-vault と lkr は特定領域に特化したツールです。.env に含まれる全てのシークレットをカバーするには、dotenvx か 1Password CLI が必要になります。 各ツールの強みと弱み aws-vault 1 $ aws-vault exec dev -- python manage.py runserver 強み 弱み STS 一時認証（15分〜で自動失効） AWS 認証情報しか管理できない AssumeRole による権限分離 macOS 限定（Keychain 依存） MFA 統合 チーム共有不可 漏洩しても短時間で無効化される 最大の強みは STS による一時認証です。他のどのツールも「漏洩しても自動で失効する」認証情報は提供できません。aws-vault が発行する一時認証情報は、仮に AI エージェントに読まれても最短15分で失効します。 ...

MCP サーバーを増やしてもコンテキストを食わせない — Claude Code の Tool Search でトークン消費を95%削減 @djrio_vr 氏のポストが、Claude Code の MCP Tool Search 機能を紹介し、大きな反響を呼んでいます（いいね 418、ブックマーク 522）。 Claude Codeで登録してるMCPサーバが増えてくるとコンテキストがかなり食われてたけど、Tool Searchという必要な時だけ動的ロードするオプションをONにしたらめちゃくちゃコンテキスト節約になった！ 環境変数 ENABLE_TOOL_SEARCH=true と設定するだけ MCP サーバーを複数接続していると、会話を始める前からコンテキストウィンドウの大部分が消費されてしまう問題は、多くの Claude Code ユーザーが直面していました。本記事では、この問題の構造と Tool Search による解決策を技術的に解説します。 MCP ツール定義がコンテキストを圧迫する構造 なぜ MCP サーバーを増やすとコンテキストが減るのか Claude Code に MCP サーバーを接続すると、各サーバーが提供する全てのツール定義がコンテキストウィンドウに読み込まれます。ツール定義には、ツール名、説明文、JSON スキーマ（パラメータの型・制約・説明）が含まれており、1つのツールだけでも数百トークンを消費します。 [MCP サーバー接続時のコンテキスト構造] システムプロンプト ～数千トークン ├── Claude Code の指示 ├── CLAUDE.md の内容 └── ユーザー設定 ツール定義 ★ ここが問題 ├── 組み込みツール（Read, Edit, Bash 等） ├── MCP サーバー A のツール × 10個 ├── MCP サーバー B のツール × 15個 ├── MCP サーバー C のツール × 20個 └── ... 会話履歴 ← 残りがここに使われる ├── ユーザーのメッセージ └── Claude の応答 具体的な数値 GitHub Issue #3036 では、約20個の MCP サーバーを接続した環境で、開始時点からコンテキスト使用率が8〜18%に達し、わずか5プロンプトで100%に到達する現象が報告されています。 ...

Readout — Claude Code の開発環境をリアルタイム監視する macOS ネイティブアプリと「エージェント監視」カテゴリの台頭 まさお@AI駆動開発(@AI_masaou)氏のポストが注目を集めています。168いいね、242ブックマークという反響は、Claude Code ユーザーが「セッション管理」と「コスト把握」に強い課題感を持っていることを示しています。 Claude Codeを日常的に使っているなら、これは知っておいたほうがいい。『Readout』— Claude Codeの開発環境をリアルタイム監視するmacOSネイティブアプリ。完全ローカル動作、アカウント不要、無料 — まさお@AI駆動開発(@AI_masaou) 紹介されている Readout は、開発者 Benji Taylor(@benjitaylor) が「自分のために作った道具」です。2026年2月27日の公開からわずか数日で英語圏・日本語圏・中国語圏に同時に広まり、AIエージェント監視という新しいツールカテゴリの勃興を象徴する存在になっています。 Readout の概要 Readout は macOS Tahoe 向けのネイティブアプリ（v0.0.6 Beta、19.8MB）です。Claude Code のセッションログをローカルで読み取り、開発環境の状態を一つのダッシュボードに集約します。 主要機能 機能 説明 リポジトリ状態 Git ブランチ、変更ファイル、ワークツリーの一覧 セッション履歴 過去の Claude Code セッションを一覧表示 APIコスト追跡 トークン消費量と推定コストのリアルタイム表示 依存関係 プロジェクトの依存パッケージの状態 設定ファイル CLAUDE.md、MCP 設定の一覧 ポート使用状況 開発サーバーのポート占有状態 セッションリプレイ Benji Taylor氏のアナウンスによると、セッションリプレイは Readout の最も注目される機能です。過去の Claude Code セッションをタイムラインで完全再生でき、以下の操作が可能です。 プロンプト、ツール呼び出し、ファイル変更を時系列で表示 再生速度の変更やステップ実行 ファイル編集時のリアルタイムハイライト これは「Claude Code が何をしたか」を事後検証するためのツールであり、セキュリティ監査やコードレビューの観点からも有用です。 Assistant 機能 バックグラウンドで開発環境をスキャンし、その情報をベースにインタラクティブな対話が可能です。ワークツリーのクリーンアップや衛生管理の修正といったアクションも実行できます。応答はリッチなコンテンツカードで表示されます。 Codex 対応 v0.0.7 で OpenAI Codex のセッション監視にも対応しました。Claude Code に限定されないマルチエージェント監視ツールへの進化が見えます。 ...