Agent

.env を AI に安心して触らせる — 1Password CLI ラッパー「opx」とプロセススコープ認証の設計 @suin 氏のポストが、AI エージェント時代の .env 管理問題に対する実践的な解決策として、自作の 1Password CLI ラッパー「opx」を公開しています。 .envをAIに安心して触らせたくて、こんなの作った AIエージェントなしではもう開発が成り立たないほど必須になってきています。権限設定がいろいろできるにせよ、本質的にAIエージェントにはプロジェクトの全ファイルを触りうる力を与えているわけで、気になるのがシークレットなどの機密情報です。 Claude Code や Cursor などの AI コーディングエージェントは、開発者と同じ権限でファイルシステムにアクセスします。.env にアクセストークンや AWS キーを平文で書いていれば、エージェントはそれを読めてしまいます。この構造的な問題に対し、「.env に機密情報を一切書かない」というアプローチで解決するのが opx です。 問題の構造 — AI エージェントが .env を読める なぜ危険なのか AI コーディングエージェントは通常のプロセスとして動作し、シェル環境を継承します。 開発者のシェル └── AI エージェント（Claude Code, Cursor 等） ├── ファイルシステムへのフルアクセス ├── .env ファイルの読み取り ├── 環境変数の参照 └── Bash コマンドの実行 .zshrc に AWS_SECRET_ACCESS_KEY を書いていれば、エージェントもそれを持っています。プロンプトインジェクション攻撃を受けた場合、エージェントが意図せず機密情報を外部に送信するリスクがあります。 実際に報告されている脆弱性 2025年末に公開された「IDEsaster」と呼ばれる調査では、Cursor、Windsurf、GitHub Copilot、Cline など30以上の AI IDE に脆弱性が発見されています。OpenAI Codex CLI では .env ファイルを経由した任意コマンド実行の脆弱性（CVE-2025-61260）も報告されました。 ...

「Claude Codeが無料で使える最強AIエージェント」は本当か — Accomplish の実態とAI煽りの再来 ガガロットAI(@gagarotai200)氏のポストが604いいね、764ブックマーク、約42,000表示と大きな反響を呼んでいます。 『Claude Code』が無料で使える最強AIエージェントが登場したww Accomplishっていうローカルで動くAIエージェントがGitHubに上がってたから共有する。これ入れれば、Claude Codeレベルの AIエージェントがサブスク購入なしで永遠に使えるwww — ガガロットAI(@gagarotai200) この投稿者は、以前「OpenClawで5人解雇」という根拠不明の煽りポストでも注目を集めた人物で、AIスクールを運営しています。今回も「最強」「無料」「永遠に使える」というキーワードが並んでいますが、主張はどこまで正確なのでしょうか。Accomplish の実態を公式情報から検証します。 Accomplish とは何か Accomplish は2026年1月13日に公開されたオープンソース（MITライセンス）のデスクトップ AI エージェントです。GitHub Stars 9.6k、Forks 1k、コントリビューター31名と、一定の支持を集めています。 基本情報 項目 内容 開発元 accomplish-ai ライセンス MIT 技術スタック Electron + React + TypeScript 対応OS macOS（Apple Silicon / Intel）、Windows 11 最新バージョン 0.3.10 内部構造 OpenCode CLI を node-pty 経由で起動 主要機能 ブラウザ自動化: Web検索、フォーム入力、データ抽出 ファイル管理: フォルダ整理、ファイル名変更、コンテンツベースの分類 ドキュメント作成: レポート作成、要約、メール下書き ワークフロー自動化: 反復タスクの自動化 対応 AI モデル カテゴリ プロバイダー クラウドAPI Anthropic（Claude）、OpenAI、Google AI、xAI、DeepSeek、Moonshot AI 等 クラウドインフラ Amazon Bedrock、Azure Foundry、OpenRouter、LiteLLM ローカル Ollama、LM Studio 主張の検証 主張1: 「Claude Codeレベルの AIエージェント」 検証結果: 大幅に誇張 ...

「MCPは死んだ、CLIに栄光あれ」— Playwright CLI が出した結論と、それでもMCPが生き残る理由 @swarm_ai_cloud 氏のポストが、@hiroki_daichi 氏が紹介した「MCP is dead. Long live the CLI」という記事に対して、Playwright CLI の登場を根拠に「結論が出た」と指摘しています。 今年1月、PlaywrightがCLIを出したことで結論出ましたね。 2026年2月、Eric Holmes の「MCP is dead. Long live the CLI」がHacker Newsのトップに上がり、85ポイント・66コメントを集めました。LLM にとって MCP は不要で、CLI で十分だという主張です。そして1月に Microsoft が Playwright CLI をリリースしたことで、この議論に具体的なデータが加わりました。 Eric Holmes の主張 — MCP は何の利益ももたらさない Holmes の記事は5つの論点で MCP の不要性を訴えています。 論点 主張 LLM に特別なプロトコルは不要 何百万もの man ページと Stack Overflow で訓練済み。CLI とドキュメントを渡せば十分 CLI は人間も使える 問題発生時に同じコマンドを人間が実行してデバッグできる。MCP は JSON ログの解読が必要 合成可能性 jq、grep、パイプで自由に組み合わせ可能。MCP サーバーの返すデータは固定 認証は解決済み aws、gh、kubectl は人間とエージェントの両方で動作する 可動部品がない CLI バイナリにバックグラウンドプロセスは不要。MCP サーバーは初期化で落ちることがある Holmes が特に強調したのは、MCP の実運用上の痛みです。 ...

236 件の AI 案件データが明かす「発注企業とベンダーの 2.5 年のズレ」— AI 受託開発市場の構造的ギャップと勝ち筋 @1edec 氏が X で公開した記事が注目を集めています。 ある製造業の担当者は、こんなことをおっしゃっていました。「役員から『AI を検討せよ』と言われたんですが、何から始めればいいかわからなくて。とりあえず相談した感じです」 @1edec 氏は 236 社の AI 関連商談データを分析し、発注企業が求めるものと AI 受託ベンダーが提供するものの間に2〜2.5 年の時間的ズレが存在することを指摘しています。本記事では、この分析が示す AI 受託開発市場の構造的ギャップと、ベンダーが取るべき戦略を解説します。 236 件の商談データが語る現実 発注企業が実際に求めているもの 236 件の商談データから浮かび上がるのは、**最先端 AI ではなく「目の前の業務課題の解決」**を求める企業の姿です。 発注企業が口にする課題キーワード: 「Excel の転記を自動化したい」 「手書き帳票をデジタル化したい」 「問い合わせ対応を効率化したい」 「在庫管理を最適化したい」 「議事録を自動で作成したい」 これらは LLM やマルチモーダル AI のような最先端技術を必要とするものではありません。OCR、RPA、チャットボットなど、既に成熟した技術で解決できる課題がほとんどです。 ベンダーが提案するもの 一方、AI 受託ベンダーの多くは、最先端の技術を前面に押し出します。 ベンダーが提案しがちな内容: 「生成 AI で業務を革新」 「LLM を活用した次世代システム」 「AI エージェントによる自律的な業務処理」 「マルチモーダル AI で非構造データを統合分析」 ここに2〜2.5 年のギャップが生まれます。ベンダーは 2026 年の最先端を提案しますが、発注企業が必要としているのは 2023〜2024 年に成熟した技術で解決できる課題なのです。 なぜ 2.5 年のズレが生まれるのか キャズム理論で読み解く AI 普及の現在地 この構造を理解するには、ジェフリー・ムーアが提唱したキャズム理論が有効です。 技術普及の 5 段階: イノベーター（2.5%） → 技術そのものに価値を見出す。PoC を自ら回す アーリーアダプター（13.5%） → 競争優位のために新技術を積極採用 ──── キャズム（深い溝） ──── アーリーマジョリティ（34%） → 「実績はあるか」「安全か」を重視。確実性を求める レイトマジョリティ（34%） → 周囲が使い始めてから導入 ラガード（16%） → 必要に迫られるまで動かない 236 件の商談データに現れる企業の多くは、アーリーマジョリティ以降の層です。「役員から AI を検討せよと言われた」という動機は、イノベーターやアーリーアダプターの特徴ではありません。「周囲がやり始めたから、うちも」という圧力で動き出した企業です。 ...

AIエージェント「デモ→本番」95%脱落 × 4つの壁とエージェンティックRAG実践 Femke Plantinga さんが、AIエージェントのデモと本番環境のギャップについて、Stack AI・Weaviate と共同作成した無料ガイドを公開しています。 95% of AI agent demos never make it to production. Yet 79% of enterprises expect full-scale agentic AI adoption within three years. So what’s the disconnect? https://x.com/femke_plantinga/status/2029134837890621844 48 いいね・8 RT を集めたこのポストが指摘するのは、AIエージェントの「デモでは動く」と「本番で使える」の間にある巨大なギャップです。MIT の調査（GenAI Divide: State of AI in Business 2025）でも、エンタープライズ向け生成AIシステムのうち本番環境に到達するのは**わずか5%**という数字が報告されています。 95%が脱落する現実 複数の調査が、AIエージェントのデモ→本番の落差を裏付けています。 調査・出典 数字 MIT GenAI Divide 2025 本番到達は全体の 5% 企業調査（探索中 30%、パイロット 38%、デプロイ準備 14%、本番稼働 11%） パイロットから先に進めない Gartner 予測 2027年までにエージェンティックAIプロジェクトの 40%以上が中止 AI施策全般 90〜95%が持続的な本番価値を提供できず、ROI達成は 12%未満 問題はモデルの性能ではなく、自律システムを運用するエンジニアリング規律の欠如です。 ...

AnimaWorks 脳科学5層記憶 × マルチエージェント「文脈崩壊」問題への解答 まさお@AI駆動開発さんが、マルチエージェントの最大の課題である「長期タスクで文脈が壊れる」問題に対して、脳科学ベースの記憶システムで挑むOSS「AnimaWorks」を紹介しています。 マルチエージェントの最大の課題「長期タスクで文脈が壊れる」に、脳科学ベースの記憶システムで挑んでいるOSSがある。それが『AnimaWorks』。エージェントを「ステートレスな関数」ではなく「組織の中の人」として設計するフレームワーク。 https://x.com/AI_masaou/status/2029134762447667373 21 いいね・2 RT を集めたこのポストが注目するのは、従来のマルチエージェントが抱えるコンテキストウィンドウの限界を、「記憶の蓄積・整理・忘却」というサイクルで乗り越えようとする設計思想です。 マルチエージェントの「文脈崩壊」問題 LLM の「記憶」の仕組み まず前提として、LLM（ChatGPT や Claude など）には人間のような記憶がありません。LLM が「覚えている」ように見えるのは、会話の全履歴を毎回テキストとして入力に含めているからです。この入力テキスト全体をコンテキストウィンドウと呼びます。 ┌─────────────────────────────────────┐ │ コンテキストウィンドウ（例: 200K トークン） │ │ │ │ システム指示 │ │ ユーザー: こんにちは │ │ AI: こんにちは！ │ │ ユーザー: Pythonで関数を書いて │ │ AI: def hello(): ... │ │ ...（数百ターンの会話履歴） │ ← 会話が長くなるほど膨らむ └─────────────────────────────────────┘ ウィンドウの物理的限界 コンテキストウィンドウには上限があります（Claude で約 200K トークン、日本語で約 10〜15 万文字）。長期タスクでは会話履歴がこの上限に達し、古い情報から順に切り捨てられます。 タスク開始時: 「このプロジェクトでは認証にJWTを使う方針です」 ← 重要な初期方針 ... 200ターン後 ... 「ログイン機能を実装して」 → エージェントは JWT の方針を忘れており、 セッション認証で実装してしまう 注意力の希釈（Lost in the Middle） ウィンドウ内に収まっていても、情報量が多すぎると LLM の「注意力」が分散します。研究では、コンテキストの先頭と末尾の情報は活用されやすいが、中間部分は見落とされやすいことが分かっています。 ...

Anthropic 公式 skill-creator の設計を解剖する — Orchestration Skill という新しいスキル設計パターン @gyakuse（逆瀬川）氏のポストが、Anthropic 公式の skill-creator を分析した記事を公開し、大きな反響を呼んでいます（いいね 330、ブックマーク 372）。 Anthropicのskill-creatorがめちゃくちゃいいスキルだったので、中身を分析して、今後どういうふうにAgent Skillを作るべきかまとめました。Orchestrator系のSkillはみんなが無意識に作りつつありますが、意識的に作ると結構便利な気がします。 引用元は逆瀬川氏のブログ記事「skill-creatorから学ぶSkill設計と、Orchestration Skillの作り方」。Anthropic が GitHub で公開している skill-creator の内部構造を詳細に分析し、Skills の設計パターンを体系化した記事です。 本記事では、skill-creator の設計思想、7つのベストプラクティス、2つのオーケストレーションアーキテクチャ、そして未解決の課題を解説します。 skill-creator とは何か 「スキルを作るためのスキル」 skill-creator は、Claude Code の Skills を作成・テスト・改善するためのメタスキルです。Anthropic が公式リポジトリ anthropics/skills で公開しています。 4つのモードで Skills の開発ライフサイクル全体をカバーします。 モード 機能 Create インタビュー → SKILL.md ドラフト作成 → テストケース生成 Eval 並列評価（スキルあり版 vs ベースライン版を同時実行） Improve 採点・分析 → HTML ビューアでレビュー → フィードバック反映 Benchmark 統計集約 → Description 最適化 → パッケージング 4つの専門エージェント skill-creator は内部で4つのサブエージェントを使い分けています。 エージェント 役割 Executor Skills を実際に実行してテスト Grader（224行） 出力を期待値と照合して採点 Comparator（203行） スキルあり版とベースライン版を盲検比較 Analyzer（275行） 結果を分析して改善提案を生成 注目すべき数値があります。SKILL.md 本体は 480行のフロー制御ですが、サブエージェントのプロンプトは合計 700行以上。オーケストレーターよりも専門家プロンプトの方が分量が多いのです。 ...

Anything の Research Agents — 「コードを書く前に調べる」AI エージェントが Vibe Coding の次に来るもの @sora19ai 氏のポストが、AI アプリビルダー Anything の新機能「Research Agents」を紹介しています。 AnythingがResearch Agentsをリリース 重要なポイント3つ： ・コードを書く前に並列エージェントがコードベースを調査 ・ファイル読み込み、パターン検索、依存関係トレースを自動化 ・ミスを大幅に削減 Anything 公式のポスト（いいね 1,093、ブックマーク 1,550）は、より明確にこの機能の意図を宣言しています。 Research Agents are live! Anything now sends parallel agents across your codebase before writing a single line of code — reading files, searching patterns, tracing dependencies, making NO mistakes. vibe coding is over. 「Vibe Coding は終わった」という挑発的な一文が目を引きます。本記事では、Research Agents が実装する「調査してから書く」アプローチの意味と、AI コーディングの次の段階を解説します。 Anything とは何か AI アプリビルダーの概要 Anything（旧称 Create）は、自然言語でアプリを構築できる AI アプリビルダーです。 ...

Claude Code Agent Skills を強化する三銃士 — scripts / references / assets の使い分け @shuhei_ohno 氏が X で投稿した、Claude Code の Agent Skills を強化するディレクトリ構造の解説が注目を集めています。 Agent Skill をもっと強くする三銃士！scripts / references / assets の使い方 Claude Code の Skills 機能は SKILL.md 1 ファイルで完結するものと思われがちですが、実際には scripts / references / assets の 3 つのサポートディレクトリを活用することで、はるかに強力な自動化が可能になります。本記事では、この 3 つのディレクトリの役割と設計パターンを、公式ドキュメントの知見を交えて解説します。 Agent Skills の基本構造 SKILL.md がすべての起点 Claude Code の Skill は、.claude/skills/ ディレクトリに配置された SKILL.md ファイルを起点として動作します。 .claude/skills/ └── my-skill/ ├── SKILL.md ← エントリポイント（必須） ├── scripts/ ← 実行可能なコード ├── references/ ← 参照ドキュメント └── assets/ ← テンプレート・バイナリ SKILL.md は Markdown 形式で記述し、オプションの YAML フロントマターでメタデータを設定します。 ...

Claude Code Skills × 自己完結スクリプト — MCP/CLI の先にある「トークン効率」設計 gunta85 さんが、Claude Code の Skill において自己完結スクリプト（Self-contained Scripts）の活用を推奨するポストを投稿しています。 Skill は MCP でも CLI ツールでもなく、Self-contained Script がおすすめ。 外部ライブラリの依存を 1 ファイル内で宣言でき、MCP に比べてトークン消費を劇的に削減できる。 https://x.com/gunta85/status/1929915853508456604 この発言の背景には、mizchi さんによる「MCP はただの CLI/API ラッパーに過ぎない」という指摘もあります。MCP のツール定義だけで数万トークンを消費する問題が顕在化するなか、Agent Skills 仕様が提供する「自己完結スクリプト」は、より効率的な選択肢として注目されています。 Agent Skills とは何か Agent Skills は、AI エージェントにドメイン知識と実行能力を付与する仕様です。agentskills.io で公開されており、Claude Code をはじめとする複数のエージェントが対応しています。 ディレクトリ構成 .claude/skills/my-skill/ SKILL.md # スキルの説明と使用手順 references/ # 参考ドキュメント（必要時のみ読込） scripts/ # 自己完結スクリプト templates/ # テンプレートファイル プログレッシブ・ディスクロージャ Agent Skills の設計思想の核心は「段階的な情報開示」です。 段階 内容 トークン目安 メタデータ frontmatter（名前・説明・引数） ~100 トークン 指示文 SKILL.md 本文 <5,000 トークン リソース references/ 配下のファイル 必要時のみ MCP サーバーがツール定義だけで大量のトークンを消費するのに対し、Skills は必要な情報を段階的に読み込むため、コンテキストウィンドウを効率的に使えます。 ...