記事一覧

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 に限定されないマルチエージェント監視ツールへの進化が見えます。 ...

インシデント対応入門 — 「バグ修正」で終わらせない組織レジリエンスの高め方 @MacopeninSUTABA 氏のポストが、SRE Lounge Hiroshima #1 で発表されたスライド資料『インシデント対応入門』を紹介しています。 『インシデント対応入門』が、全エンジニア・PMに刺さる。単なる「バグ修正」で終わらせない、組織としてのレジリエンスの高め方を徹底解説している。 著者の gr1m0h 氏は、インシデントマネジメント SaaS「Waroom」を開発する Topotal 社のソフトウェアエンジニア兼 SRE です。このスライドは閲覧数 5,600 を超え、エンジニアやPMの間で広く共有されています。本記事では、スライドの内容を軸に、インシデント対応の5つのフェーズとその実践方法を掘り下げます。 なぜ「バグ修正」では不十分なのか 障害が起きたとき、コードを直して「修正完了」で終わりにしていないでしょうか。しかし、同じ種類のインシデントが繰り返し発生する組織は少なくありません。その原因は、インシデント対応を「技術的な修正」だけで完結させてしまうことにあります。 gr1m0h 氏のスライドが提示するのは、インシデント対応を5つのフェーズで捉えるフレームワークです。修正は全体のプロセスの一部に過ぎず、準備・検知・振り返り・恒久対応まで含めた組織的な取り組みが必要です。 5つのフェーズで捉えるインシデント対応 フェーズ1: 準備 インシデントが発生する前の体制整備です。「準備がないと『どうする？』から始まる」という指摘は、多くの現場で実感があるのではないでしょうか。 具体的に準備すべき項目は以下の通りです。 緊急度基準の策定: インシデントの重大度（SEV）を定義する 連絡ルールの文書化: 誰が、誰に、どの手段で連絡するかを明文化する 手順書の作成: 初動対応の手順を事前に整備する 監視設定: アラートの閾値やエスカレーション条件を設定する SEV（重大度）レベルの定義例 スライドでは4段階の重大度レベルが紹介されています。 レベル 状態 対応の緊急度 SEV1 サービス全体が停止 即座に全員招集 SEV2 主要機能の障害 速やかに対応チーム編成 SEV3 一部機能の劣化 営業時間内に対応 SEV4 軽微な問題 通常優先度で対応 重要なのは、この基準が事前に合意されていることです。インシデント発生時に「これはSEV1なのか2なのか」を議論している時間はありません。 フェーズ2: 検知・初動 「『様子見』している間にも被害は広がる」というスライドの指摘は、初動の遅れがインシデントの影響を拡大させる現実を端的に表しています。 検知・初動で行うべきことは以下の4つです。 状況確認: 何が起きているかを把握する 影響範囲の特定: どのユーザー・機能に影響しているかを確認する 緊急度の判定: SEV レベルを判断する 関係者への連絡: 定められたルールに従ってエスカレーションする フェーズ3: 対応・復旧 対応フェーズで最も重要な原則は、指揮と作業の分離です。 ...

クリーンアーキテクチャという「型」の暴力 — 過剰な抽象化が現場を壊すメカニズム @sside 氏が X で投稿した、クリーンアーキテクチャの過剰適用への批判が反響を呼んでいます。 クリーンアーキテクチャかぶれの糞プロジェクト、異なる会社で2度目撃しました。(どっちもNestJS) この投稿は、@masuda220（増田亨）氏のツイートへの引用です。増田氏は以下のように述べています。 私の狭い観測範囲ではあるけれど、クリーンアーキテクチャを取り入れていると説明されたコードを見ると、過剰な変換コードと過剰な依存性の逆転をしているものが多い。実験目的であれば、やりすぎるのもありだと思うが、実プロダクトでは、不要な複雑さを持ち込んで苦しんでいるように見える。 2 人の指摘は、日本のエンジニアコミュニティで繰り返し議論されてきた「クリーンアーキテクチャのカーゴカルト問題」を改めて可視化しています。本記事では、クリーンアーキテクチャとは何か、カーゴカルトとは何かを整理した上で、なぜこの問題が繰り返し起きるのかを構造的に分析します。 クリーンアーキテクチャとは何か 起源と系譜 クリーンアーキテクチャは、Robert C. Martin（通称 Uncle Bob）が 2012 年にブログで提唱し、2017 年に書籍『Clean Architecture: A Craftsman’s Guide to Software Structure and Design』として体系化した設計思想です。 この思想は突然生まれたものではなく、先行するアーキテクチャパターンの集大成です。 年 アーキテクチャ 提唱者 核心 2005 ヘキサゴナルアーキテクチャ（Ports and Adapters） Alistair Cockburn アプリケーションを外部から分離する 2008 オニオンアーキテクチャ Jeffrey Palermo 依存関係を内側に向ける 2012 クリーンアーキテクチャ Robert C. Martin 上記を統合し SOLID 原則と結びつける クリーンアーキテクチャが新たに発明したものは実はほとんどありません。ヘキサゴナルアーキテクチャとオニオンアーキテクチャのルールを包含し、SOLID 原則（特に依存性逆転の原則）を軸に再構成したものです。 同心円図と依存性ルール 書籍で最も有名なのが、4 層の同心円図です。 ┌─────────────────────────────────────────┐ │ Frameworks & Drivers（外側） │ │ ┌───────────────────────────────────┐ │ │ │ Interface Adapters │ │ │ │ ┌─────────────────────────────┐ │ │ │ │ │ Application Business Rules │ │ │ │ │ │ ┌───────────────────────┐ │ │ │ │ │ │ │ Enterprise Business │ │ │ │ │ │ │ │ Rules（中心） │ │ │ │ │ │ │ └───────────────────────┘ │ │ │ │ │ └─────────────────────────────┘ │ │ │ └───────────────────────────────────┘ │ └─────────────────────────────────────────┘ 依存性ルール: すべての依存は外側から内側に向かう（→ 中心） 依存性ルールがこのアーキテクチャの柱です。外側の層（フレームワーク、DB、UI）が内側の層（ビジネスロジック）に依存し、逆方向の依存は許されません。これにより、ビジネスロジックはフレームワークやデータベースの変更に影響されず、テスト可能で長寿命なコードになるとされています。 ...