Agent

.env の代わりに aws-vault で安全に環境変数を与える — Claude Code 時代の AWS 認証情報管理 AI エージェントがローカルファイルを直接読み書きする時代、.env に平文で認証情報を置くリスクが顕在化しています。前回の記事では、この問題の背景と複数のシークレット管理ツールを紹介しました。 本記事では、AWS を利用しているチームに向けて、aws-vault を使って .env と ~/.aws/credentials を完全に排除する具体的な手順を解説します。 aws-vault が解決する問題 ~/.aws/credentials の平文問題 AWS CLI を使う開発者の多くは、~/.aws/credentials にアクセスキーを平文で保存しています。 1 2 3 4 # ~/.aws/credentials（平文で保存されている） [default] aws_access_key_id = AKIAIOSFODNN7EXAMPLE aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY このファイルには2つのリスクがあります。 Claude Code が読み取れる: AI エージェントがファイルシステムを探索する際、~/.aws/credentials のアクセスキーが LLM のコンテキストに載る可能性がある 長期的な認証情報が漏洩する: アクセスキーには有効期限がなく、漏洩した場合は手動でローテーションするまで悪用され続ける aws-vault のアプローチ aws-vault は以下の2段階で問題を解決します。 暗号化保存: アクセスキーを ~/.aws/credentials ではなく、OS のキーストア（macOS Keychain 等）に暗号化して保存する 一時認証の生成: AWS STS（Security Token Service）を使って、1時間で失効する一時認証情報を生成し、子プロセスに注入する [従来] ~/.aws/credentials（平文） → AWS CLI / boto3 が直接読み取り → 長期キーがメモリに残る [aws-vault] macOS Keychain（暗号化） → aws-vault が STS で一時認証を生成 → 子プロセスに環境変数として注入 → 1時間で失効 セットアップ インストール 1 2 3 4 5 6 7 8 9 10 11 12 13 # macOS（推奨） brew install --cask aws-vault # macOS（Homebrew formula 版） brew install aws-vault # Linux brew install aws-vault # Windows choco install aws-vault # または scoop install aws-vault macOS では --cask 版が推奨されています。コード署名されているため、Keychain アクセス時の追加のパスワードプロンプトが少なくなります。 ...

「OpenClawで5人解雇」は本当か — AIエージェント煽りの構造とファクトチェック ガガロットAI(@gagarotai200)氏のポストが拡散されています。 「Open Claw」を使い始めた企業では既に5人以上の人間が解雇になっている。仮想オフィスでAIエージェントを擬似的に社員の様に働かせて進捗を確認できる様になったことで人間がタスクをこなす必要性がなくなっている — ガガロットAI(@gagarotai200) さらに「今後5年で中小企業の30%はAI社員に置き換わる」「GPTやGeminiしか触ってない人は残り3ヶ月程度で不要になる」と煽っています。この主張はどこまで事実に基づいているのでしょうか。国際機関の統計とセキュリティ研究者の報告をもとにファクトチェックします。 主張を検証する 主張1: 「OpenClaw導入企業で5人以上が解雇」 検証結果: 根拠不明 この「5人以上の解雇」について、具体的な企業名、業種、時期、情報源は示されていません。投稿者のプロフィールを確認すると、ガガロットAI氏は「スキルエンジン」というAIスクールを運営し、SNS運用代行を50社に提供しているとのことです。つまり、OpenClawの普及が自身のビジネスに直接利益をもたらす立場にあります。 TechCrunch の報道では、AI専門家が「AIリサーチの観点から見て、これは何も新しいものではない」と指摘しています。 主張2: 「集客・提案書作成・顧客対応は完全AI化」 検証結果: 大幅に誇張 Cobus Greyling氏のMedium記事は、OpenClawが実際に失敗するケースを分析しています。「高い能力を持つという評判」と「messy, unpredictable reality（混沌とした予測不能な現実）」の間にはギャップがあり、実用には人間の監視が不可欠です。 具体的な暴走事例も報告されています。 事例 内容 iMessageループ エンジニアChris Boyd氏の環境で確認メッセージを繰り返し送信。再試行ロジックに停止条件がなかった 批判ブログ自動公開 matplotlibメンテナーがコード提案を却下後、自身を批判するブログ記事が自動公開された デーティングサイト暴走 想定以上に広範な自動行動が発生し、制御不能に 「完全AI化」どころか、監視なしでは予期せぬ行動を起こすリスクが確認されています。 主張3: 「今後5年で中小企業の30%はAI社員に置き換わる」 検証結果: 出典なし。国際機関の予測と乖離 この「30%」という数字の出典は示されていません。実際の国際機関の予測と比較してみましょう。 機関 予測内容 OECD (2023) 27%の職業が自動化のリスクが高い（「置き換え」ではなく「リスクがある」） ILO (2023) 事務業務の24%が高度に曝露、58%が中程度に曝露（「解雇」ではなく「影響を受ける」） Gartner 2027年までにエージェント型AIプロジェクトの40%以上が失敗する JILPT (2024) 日本の雇用者のうちAIが使用されている者は12.9%、生成AIを自ら利用している者は6.4% 注意すべきは、OECD や ILO の予測は「影響を受ける」「曝露される」であり、「置き換わる」「解雇される」ではないことです。さらに、日本の中小企業（10人未満）のAIエージェント導入率は10%以下という現状を考えると、「5年で30%置き換え」は根拠のない数字と言えます。 主張4: 「GPTやGeminiしか触ってない人は残り3ヶ月で不要」 検証結果: 煽り文句 具体的な根拠はなく、不安を煽ってAIスクールへの誘導を意図した表現と見られます。 OpenClawの実態 — セキュリティリスクの深刻さ 「AIが人間を置き換える」と煽る前に、OpenClaw自体が抱えるセキュリティリスクを確認すべきです。 悪意あるスキルの蔓延 セキュリティ企業Koi Securityの監査によると、ClawHub（OpenClawの公式スキルストア）に登録された2,857スキルのうち341件（約12%）が悪意あるコードを含んでいたことが判明しています。 ...

AI が書いた CLAUDE.md は逆効果 — 「コンテキストファイルの自動生成は精度を下げる」という研究 @at_sushi_（門脇敦司）氏が X で投稿した、AI 生成のプロンプトファイルに関する記事が注目を集めています。 CLAUDE.md のようなプロンプトファイルを AI に生成させると「逆に精度が下がる」という研究です。AI 文書は冗長で、AI 自身を混乱させます。では、どうすればいいのか？ というと、「本当に重要な情報だけを、開発者が書く」というのが現在の正解です 元記事は Zenn の解説記事で、ETH Zurich と LogicStar.ai の研究チーム（Gloaguen et al.）による論文「Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?」を日本語で紹介しています。本記事では、この研究の実験データを詳しく読み解き、CLAUDE.md / AGENTS.md の書き方への実践的な示唆を整理します。 研究の概要 — 何を検証したのか 背景 CLAUDE.md、AGENTS.md、CURSORRULES — これらの「コンテキストファイル」は、AI コーディングエージェントにリポジトリの慣習や制約を伝えるための指示書です。Anthropic、OpenAI、Cursor はいずれもこれらのファイルの作成を強く推奨しています。 しかし、「コンテキストファイルは本当にエージェントの性能を向上させるのか?」 という基本的な問いに対して、厳密な検証はこれまで行われていませんでした。 実験設計 ETH Zurich の研究チームは、3 つの条件で比較実験を実施しました。 条件 内容 なし（None） コンテキストファイルなし（ベースライン） LLM 生成 エージェント開発者の推奨に従い LLM に自動生成させたファイル 人間作成 開発者がリポジトリにコミットしたファイル 評価対象モデル: Claude Code（Sonnet 4.5）、Codex（GPT-5.2 / GPT-5.1 mini）、Qwen Code（Qwen3-30b-coder） ...

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 は「不完全な個体の協力」を前提に設計されており、現実の企業組織と同じく、情報の非対称性やコミュニケーションコストを意図的に組み込んでいます。 ...

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分で失効します。 ...

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

個人のファインチューニング済みモデルを P2P で相互利用する — 分散 MoE で「みんなの AI」は成立するか 先の記事「オープンソース AI は『無料』でも『民主化』でもない」で取り上げた Dario Amodei の指摘 — 推論には高価な計算資源が必要であり、重みの公開だけでは真の民主化にならない — に対して、興味深い反論の構想があります。 Qwen 3.5 のような軽量モデルを各個人が自分のドメインでファインチューニングし、P2P ネットワークで互いのエージェントに相互利用させれば、大規模 LLM と同等の仕組みを分散的に構築できるのではないか? この構想を技術的に検証します。 構想の全体像 — 分散 Mixture of Experts この発想は、商用 LLM の内部で使われている Mixture of Experts（MoE） アーキテクチャを、P2P ネットワーク上に展開したものと捉えることができます。 個人A: Qwen 3.5 (法律ドメインでファインチューニング) 個人B: Qwen 3.5 (医療ドメインでファインチューニング) 個人C: Qwen 3.5 (プログラミング特化) 個人D: Qwen 3.5 (会計・税務特化) 個人E: Qwen 3.5 (マーケティング特化) ↓ P2P ルーティングレイヤー（質問の性質に応じて最適なノードを選択） ↓ エージェントが複数の専門モデルを横断的に活用 商用 LLM が「1 つの巨大なモデル内でエキスパートを切り替える」のに対し、この構想は「ネットワーク上の独立した専門モデルを切り替える」アプローチです。 なぜ今この構想が現実味を帯びているのか 3 つの技術的な進歩が、この構想を「空想」から「検討に値する」レベルに引き上げています。 ...

AIエージェントの勝負所は「モデル性能」ではなく「ハーネス設計」にある はじめに 2026年に入り、AIエージェント開発の世界で急速に広まっている概念がある。「Agent Harness（エージェント・ハーネス）」 だ。 LLMの性能は日々向上し、Claude Opus 4.6、GPT-5、Gemini 2.5 Pro といったモデルが次々とリリースされている。しかし、現場のエンジニアたちは気づき始めている——同じモデルを使っていても、エージェントの体感品質はまるで別物になるということに。その差を生むのがモデルの「外側」にある仕組み、すなわちAgent Harnessである。 この記事では、Philipp SchmidのAgent Harness論、Lance MartinのContext Engineering解説、そしてManusの実装例を手がかりに、エージェント開発の新しいパラダイムを整理する。 Agent Harness・AIエージェント・LLM の関係 まず、3つの概念の関係を整理する。混乱しやすいのは、これらが入れ子構造になっているからだ。 レイヤー構造 graph TB subgraph UserLayer["ユーザー"] U["指示を出す / 結果を受け取る"] end subgraph AgentLayer["AIエージェント = アプリケーション層"] A1["ユーザー固有のロジック・目的"] A2["例: コードアシスタント、リサーチエージェント、カスタマーサポートBot"] end subgraph HarnessLayer["Agent Harness = OS層"] H1["コンテキスト管理 / ツール実行 / 権限制御"] H2["メモリ管理 / 再試行 / フォールバック / 承認ポイント"] end subgraph LLMLayer["LLM = CPU層"] L1["言語理解・推論・生成"] L2["例: Claude Opus 4.6, GPT-5, Gemini"] end UserLayer --> AgentLayer AgentLayer --> HarnessLayer HarnessLayer --> LLMLayer Philipp Schmidのコンピュータの比喩を使うと： ...

Claude Code スキルで AI ワークフローを自動化する — Ralph Loop + YAML 宣言的定義の実践 kenfdev さん（@kenfdev）が、Claude Code のスキル機能を活用した AI エージェントのワークフロー自動化について、実践的な技術記事を公開しています。 Claude Code のスキルを中心に、AIエージェントのワークフローを自動化してみた話を書きました。 bash の while ループで claude -p を繰り返す Ralph Loop と、YAML でワークフロー定義を組み合わせて、plan → implement → review → finalize を自律的に回す仕組みです。 TAKTほどの精度には及ばないのですが、それなりに自分のワークフローでは活用できています。 — kenfdev (@kenfdev) 記事の核は「Ralph Loop」と「YAML ワークフロー定義」という 2 つの技術を Claude Code スキルで統合し、plan → implement → review → finalize を自律的に回す仕組みです。 Ralph Loop とは何か 起源 Ralph Loop（正式には Ralph Wiggum Loop）は、Geoffrey Huntley が考案した AI 開発自動化パターンです。名前はシンプソンズのキャラクターに由来しますが、仕組み自体は極めてシンプルです。 基本構造 1 2 3 4 5 6 7 while true; do result=$(claude -p "プロンプト") # 完了判定 if [[ "$result" == *"COMPLETE"* ]]; then break fi done bash の while ループで claude -p（ヘッドレスモード）を繰り返し呼び出す、たったこれだけです。-p フラグは Claude Code を非対話モードで実行し、結果を標準出力に返します。 ...

Claude Code スキルで「穴場市場」を自動発掘 — コードを書かない AI エージェント活用術 「Claude Code はプログラミング支援ツール」——そう思い込んでいませんか？ @koder_dev さんのポスト で紹介された Zenn 記事（s4kura 氏） が話題になっています。Claude Code の スキル機能 を使って「穴場市場を探させる」という、コーディングとは全く異なる使い方です。 「Claude Code にスキル自作させて穴場市場探させるって Zenn の記事めっちゃ面白かった。いや本当自分の周りも自作 skill でプログラミング作って色んな作業やらせてる、無限に応用効くからなー」— @koder_dev Claude Code スキルとは何か 基本概念 Claude Code のスキルは、SKILL.md ファイルに指示を記述することで Claude の機能を拡張する仕組みです。いわば 「プロンプトエンジニアリングのパッケージ化」 です。 スキルなし: 毎回 → 「こういう手順で」「こういう基準で」「こういう形式で」と指示 結果 → 指示漏れ、品質のばらつき スキルあり: 毎回 → /skill-name と入力するだけ 結果 → 事前定義した手順・基準・形式が自動適用 スキルの構造 スキルは SKILL.md を中心としたディレクトリです。 my-skill/ ├── SKILL.md # メイン指示（必須） ├── references/ # 判断基準・リファレンス（任意） ├── templates/ # テンプレート（任意） ├── scripts/ # 実行スクリプト（任意） └── examples/ # サンプル出力（任意） SKILL.md は YAML フロントマターとマークダウンコンテンツの 2 部構成です。 ...