AI/LLM

Shannon — 自律型 AI ペネトレーションテスターが「実証なき報告」を終わらせる @heynavtoor 氏のポストが話題になっています。 Someone just open sourced a fully autonomous AI hacker and it’s terrifying. It’s called Shannon. Point it at your web app, and it doesn’t just scan for vulnerabilities. It actually exploits them. Shannon は「No Exploit, No Report（実証できなければ報告しない）」を原則とする、完全自律型の AI ペネトレーションテストツールです。従来のスキャナーが「ここが危険かもしれません」と警告を出す場面で、Shannon は実際に攻撃を実行し、成功した場合だけ報告します。XBOW ベンチマークで 96.15% のスコアを記録し、GitHub で 10,000 以上のスターを獲得しています。 なぜ Shannon が注目されるのか — 年 1 回ペンテストの限界 現代の開発チームは Claude Code や Cursor を使い、毎日コードを出荷しています。一方、ペネトレーションテストは年 1 回が一般的です。365 日のうち 364 日は「検証なし」で本番にデプロイしている計算になります。 ...

.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 Ads」の正体 — Anthropic 公式ではない個人開発スキルが日本でバズった構造を解剖する @lapper_s_high 氏のポストが、「Claude Ads」の名前が引き起こした混乱を端的に指摘しています（いいね 482）。 開発者も日本でこんなに話題になるなんて思わなかったのでは・・ Claude Adsなんて名前つけるから。。 引用元の @ryottaman 氏のポスト（表示 27万、ブックマーク 390）が拡散の起点となり、日本の SNS では「Anthropic が広告運用ツールを出した」という誤解が広がりました。 実際には、Claude Ads は **Anthropic の公式製品ではなく、個人開発者が GitHub に公開した Claude Code 向けのスキル（拡張機能）**です。本記事では、なぜこの混乱が起きたのか、Claude Ads の実態は何なのか、そして Claude Code のスキルシステムがどのように機能するのかを解説します。 なぜ混乱が起きたのか — 3つの偶然の重なり 偶然1: Anthropic のスーパーボウル CM 2026年2月、Anthropic はスーパーボウル第60回大会で CM を放映しました。キャッチコピーは 「Ads are coming to AI. But not to Claude.」（広告は AI にやって来る。だが、Claude には来ない）。OpenAI が ChatGPT への広告導入を発表した直後のタイミングで、「Claude は広告を入れない」と宣言する内容でした。 この CM は大きな話題となり、OpenAI の Sam Altman CEO が「面白いが明らかに不誠実」と反論する事態にまで発展しています。 偶然2: 「Claude Ads」という名前 その直後、個人開発者の Daniel Agrici 氏が GitHub に公開したのが claude-ads です。これは Claude Code で広告アカウントを監査するスキルであり、「Claude を使って Ads（広告）を分析する」という意味での命名でした。 ...

「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エージェント」 検証結果: 大幅に誇張 ...

「Figma は 100% 不要」宣言の真意 — Claude Code が溶かすデザインとコードの境界 @kawai_design 氏が X で公開した記事が議論を呼んでいます。 Claude Code を使えば使うほど、Figma を開く理由が消えていく。これは私だけの感覚ではありません。今、世界中のデザイナーが同じ疑問を抱えています。私の結論は明確です。Figma は 100% 不要。 同時期に UX Collective に掲載された Michael Buckley 氏の記事「Figma はデザインツールではない。コードを避けるためのピタゴラスイッチだ」も世界のデザイナーを震撼させました。本記事では、この「Figma 不要論」の構造と、Figma 自身の対応、そして AI 時代のデザインワークフローの変化を技術的に整理します。 「ピタゴラスイッチ」批判 — 何が問題なのか UX Collective の記事が突いた急所 Michael Buckley 氏の記事は、Figma でのデザイン作業を**ルーブ・ゴールドバーグ・マシン（ピタゴラスイッチ）**に例えました。 Figma でボタンを作る作業: 1. Auto Layout を設定する 2. パディングを調整する 3. ホバーステートを作る 4. インタラクションを設定する 5. プロトタイプモードで動作確認する 6. 開発者に引き渡す 7. 開発者がコードで再実装する 開発者が同じボタンを作る作業: <button className="btn-primary">送信</button> → 5 分で完了。ホバー、アクセシビリティも含めて 「パンケーキを返すためにピタゴラスイッチを作るようなもの」— この比喩が刺さったのは、多くのデザイナーが無意識にこの非効率を受け入れていたからです。 本質的な問題: デザインとコードの「翻訳」 Figma の存在意義はデザインとコードの間の翻訳レイヤーにあります。 従来のワークフロー: デザイナーの意図 → Figma でビジュアル化（翻訳 1） → デザインスペック作成（翻訳 2） → 開発者がコードに変換（翻訳 3） → 実装結果をデザイナーがレビュー（逆翻訳） 翻訳のたびに情報が劣化する: - ピクセルのズレ - インタラクションの解釈違い - レスポンシブ挙動の不一致 - アクセシビリティの抜け漏れ AI がデザインの意図を理解し、直接コードを生成するようになれば、この翻訳プロセス自体が不要になります。@kawai_design 氏の「翻訳の元データである Figma ファイルも要りません」という指摘は、ここに根ざしています。 ...

「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 の実運用上の痛みです。 ...

「テスト書いて」と「テスト駆動で実装して」は全く別物 — AI×TDD で品質が劇的に変わる構造的理由 @neurostack_0001 氏のポストが、AI にテストを書かせる際の決定的な違いを指摘し、大きな反響を呼んでいます（いいね 267、ブックマーク 222）。 3ヶ月AIにテストコード書かせてわかったこと。 「テスト書いて」と「テスト駆動で実装して」は全く別物だった。 3ヶ月間の実体験から導き出された結論は明快です。AI に「テストを書いて」と頼むのと「テスト駆動で実装して」と頼むのでは、出力されるテストの品質が根本的に異なる。本記事では、なぜこの違いが生まれるのか、その構造的な理由と実践的なワークフローを解説します。 「テスト書いて」が失敗する構造 テスト後付けバイアス ポスト主が最初に経験した失敗パターンは、多くの開発者に共通するものです。 最初はClaude Codeに「この関数のテスト書いて」と頼んでた。構文は完璧。でも実行すると半分以上落ちる。テスト対象もモックしてたり、存在しないメソッド呼んでたり。「テストっぽいもの」を量産してただけ。 この問題はテスト後付けバイアスと呼ばれる LLM の構造的な弱点に起因します。LLM が実装コードを見てからテストを生成する場合、テストは「コードが何をすべきか」ではなく「コードが何をしているか」を検証するものになりがちです。 具体的に発生する問題は以下の通りです。 問題 説明 テスト対象のモック化 テストすべき関数自体をモックしてしまい、実際のロジックを検証していない 存在しないメソッド呼び出し LLM のハルシネーションにより、実在しない API やメソッドをテストで使用する 実装への密結合 内部実装の詳細に依存するテストが生成され、リファクタリングで壊れる 網羅性の欠如 エッジケースや異常系のテストが不足し、正常系のみカバーする なぜ LLM は「テストっぽいもの」を量産するのか Codemanship の記事が、この問題の本質を指摘しています。 The more things we ask models to pay attention to, the less able they are to pay attention to any of them. LLM は「次の最も確率の高いトークン」を予測する仕組みです。既存の実装コードをコンテキストに含めてテストを生成すると、モデルは実装の構造を模倣したテストを生成します。テストとしての妥当性ではなく、「テストとして見た目がそれらしいもの」を出力するのです。 これは LLM の根本的な限界であり、プロンプトの工夫だけでは解決できません。 「テスト駆動で実装して」が品質を変える理由 テストファーストが生む構造的な違い ポスト主が発見した転機は、TDD のループを AI 自身にやらせることでした。 ...

「作れること」の価値が消える AI 時代に、SRE / プロダクション・エンジニアリングの重要性が上がる理由 integrated1453氏のポストが、すてぃお（@suthio_）氏の note 記事「『作れること』の価値が消えていくAI時代にソフトウェアエンジニアは何をやるべきか」に対して、SRE の視点からコメントし、98いいね、81ブックマーク、約12,600表示と反響を呼んでいます。 エンジニアにとって、より高度にSREをやっていくことの重要性が上がるという話だと思った。プロダクションで起こっている問題をデバッグして修正して再発防止するとか、それらを再現性高く実行できる仕組みを作るとか、SREがやる運用のエンジニアリングそのもの。まずは障害対応100本ノックしよう！笑 — integrated1453 元のすてぃお氏の投稿は552いいね、759ブックマーク、約87,900表示とさらに大きな反響です。すてぃお氏は adding Inc. 代表取締役で、元スタートアップ CTO。Claude Code の登場以降、AI 時代のエンジニア像について一貫した発信を続けています。 すてぃお氏の主張 — 「作れる」から「動かし続ける」へ 核心のテーゼ すてぃお氏の一連の記事を横断する主張は明確です。 Claude Code を使い始めてから、僕の開発方法は根本的に変わりました。以前は「この処理を実装するのに3日くらいかかるな」と見積もっていたものが、今は適切な指示を出せば30分で形になる。 実装スキル単体の市場価値が低下し、求められるのは以下の能力だという主張です。 低下する価値 上昇する価値 コードを書く能力 コードを読んで検証する能力 実装の速さ 仕様・制約の設計力 個別機能の開発 自己修復・自己改善するシステムの設計 技術力単体 技術力 × ビジネス力 すてぃお氏の提案する3つの方向性 「勝手に動き続ける仕組み」を作る: 修正する人ではなく、自己修復・自己改善するシステムの設計者になる コードは「読めるけど書けない」でいい: エンジニアの主要業務が「書く能力」から「読む能力」へ転換 事業成長にコミットする: 技術へのコミットメントよりも事業成長へのコミットメントが重要 integrated1453 氏の洞察 — これは SRE の話だ integrated1453 氏のコメントの核心は、すてぃお氏の「動かし続ける仕組みを作る」という主張を、SRE（Site Reliability Engineering）のコンテキストに接続したことです。 SRE が担う「動かし続ける」 すてぃお氏の表現 SRE の対応する実践 自己修復するシステム Self-healing infrastructure、自動ロールバック 自己改善するシステム ポストモーテムからの自動ガードレール生成 再現性高く実行できる仕組み Infrastructure as Code、ランブック自動化 プロダクションの問題をデバッグ オブザーバビリティ、分散トレーシング 再発防止 SLO/SLI 定義、エラーバジェット管理 「作れること」の価値が下がるなら、「動かし続けること」の価値が相対的に上がる。これは論理的に自然な帰結です。 ...

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 プロンプトのベストプラクティスは「プロの手順」の踏襲 — 要件定義から実装まで 5 段階に分ける gohan 氏（@grandchildrice）が、Cursor アンバサダーの Kinopee 氏のツイートを引用して次のように投稿しています。 AIプロンプトのベストプラクティスは「プロの人間はどういう手順を取る？」を徹底して踏襲すること システム開発するとなったらざっくり ゴールと要件定義 要件定義の検証 テスト工程設計 開発 テスト バイブコーディングするときも、1〜5でそれぞれプロンプトを分けるとクオリティは格段に上がる — gohan 引用元の Kinopee 氏（@kinopee_ai）は 2,048 いいね・35 万回表示を記録したツイートで、こう述べています。 壁打ちして、いきなり「それで実装して」ではなく、このひと手間をかけるだけで、結果が全然違いますよ — Kinopee 「ひと手間」とは何か。要件定義と実装の間に「検証」と「テスト設計」を挟むことです。この記事では、プロの開発プロセスを AI プロンプトに適用する具体的な方法を解説します。 なぜ「一発プロンプト」は失敗するのか 多くの人がバイブコーディングでつまずく原因は、1 つのプロンプトですべてを済ませようとすることにあります。 ❌ 「経費精算アプリを作って」 この指示は、人間の開発チームに例えれば「要件定義も設計もテストも全部同時にやって」と言っているのと同じです。プロの開発者はそんなことはしません。 LLM は 1 つのプロンプトに複数の目的を詰め込むと、各目的の達成度が下がります。要件定義の精緻さ、テスト設計の網羅性、実装の品質が、すべて中途半端になります。 5 段階プロンプト設計 gohan 氏が提唱する 5 段階は、ソフトウェア開発の V 字モデルを簡略化したものです。各段階で別々のプロンプトを使うことで、AI の出力品質が格段に向上します。 第 1 段階：ゴールと要件定義 目的: 「何を作るか」を言語化する このアプリのゴールは「月次経費精算の手作業を 30 分から 5 分に短縮する」ことです。 以下の要件定義書を作成してください： - ユーザーストーリー - 機能要件（入力・処理・出力） - 非機能要件（性能・セキュリティ） - 制約条件（使用する外部サービス、予算） ポイントはゴールを定量的に書くことです。「便利なアプリ」ではなく「30 分を 5 分に短縮」と書けば、AI が判断基準を持てます。 ...