AI/LLM

NTTデータの茂呂 範さんが Zenn に投稿した記事「設計書・コード・テストを全部AIに書かせて半年間開発してみたよ」が大きな反響を呼んでいる。2025年10月から2026年3月の6ヶ月間、設計書・ソースコード・テストケースの一切を AI に生成させ、社員はレビューのみに徹したという取り組みだ。 プロジェクト概要 期間: 2025年10月〜2026年3月（約6ヶ月） 対象: 商用システムのサブシステム（グリーンフィールド開発） アーキテクチャ: TERASOLUNA（NTTデータ標準）+ AWS 利用 AI: GitHub Copilot 体制: 社員3名（開発担当 + 経験豊富なメンター社員で構成） 社員は設計書・ソースコード・テストケースを1行も手で書かなかった、というのが最大の特徴だ。 AI ネイティブ開発の実態 ファイル構成と規模 .github ディレクトリだけで133ファイル、約9,000行（空行除く）のコードが生成された。プロンプト定義やワークフロー設定も含め、インフラ構成に至るまで AI が出力したものをレビュー・採用している。 コンテキスト管理の工夫 LLM のコンテキストウィンドウ制約に対処するため、以下の設計方針を採用した。 個別ファイルをできるだけ小さく保つ ファイル間参照を最小化し、コンテキストの柔軟性を維持する INPUT/OUTPUT 仕様書へのシフト 従来の詳細設計書は「処理フロー」を細かく記述するものだった。今回は発想を転換し、INPUT/OUTPUT 仕様のみを AI に渡す アプローチを採った。ロジックの実装は AI に委ねることで、設計書の記述コストを大幅に削減している。 反響：大手 vs. 個人開発者 このアプローチに対し、個人開発者の @HAL1986____ 氏は X (Twitter) で次のようにコメントした。 さすがNTTデータ、という感じ。 正直、このレベルを本気でやられてしまうと、純粋な開発力では全く太刀打ちできないのよな。 僕らは大手に出来ない戦い方をしないとダメだな。 組織として標準アーキテクチャ・標準ツール・大規模なレビュー体制を揃えた上で AI を活用する大企業と、個人や小規模チームが同じ土俵で戦うことの難しさを端的に表している。 大手企業が AI をエンタープライズの開発プロセスに正式に組み込み始めた今、スモールチームが取るべき戦略は「大手が苦手な領域」への集中と差別化かもしれない。 まとめ NTTデータの事例は、AI 駆動開発が「実験」ではなく「本番商用システム」レベルに到達したことを示す重要なマイルストーンだ。 設計書の書き方を INPUT/OUTPUT 仕様書にシフト コード・テストの生成を AI に全面委任 社員はレビュー・品質担保に集中 この流れは今後さらに加速するだろう。開発者が問われるのは「コードを書く力」より「AI の出力を正しく評価・修正できる力」になりつつある。 ...

MetaのGenAIチーム（LLaMA）出身のCo-FounderであるPeter Pang（@intuitiveml）が率いるエージェントプラットフォーム企業CreaoAI（25名）が、「AIファースト」を本気で実践した結果、コードの99%をAIが書き、かつてのリリースサイクル6週間を1日に短縮した方法を解説している。 元記事タイトルは “Why Your ‘AI-First’ Strategy Is Probably Wrong”。@SuguruKun_ai がX（旧Twitter）のスレッドで日本語解説している。 AIを「導入した」会社と「前提に組み直した」会社の違い 多くの企業は既存のプロセスにAIを乗せています。エンジニアがCursorを開き、PMがChatGPTで仕様書を書く――ワークフローは変わらず、効率が10〜20%上がるだけです。 AIファーストとはまったく別物です。AIファーストとは、「AIがメインのビルダーである」という前提でプロセス・アーキテクチャ・組織を再設計することです。「どうすればAIがエンジニアの役に立てるか？」ではなく、「どう再構築すればAIがビルドし、エンジニアが方向と判断を提供できるか？」という問いです。 ハーネスエンジニアリングとは何か OpenAIが2026年2月に発表した概念で、CreaoAIが実践の中で独自に到達していたアプローチと一致しました。 エンジニアリングチームの主な仕事はもはやコードを書くことではなく、エージェントが有用な作業を行える「環境（ハーネス）」を整えることである。 失敗が起きたとき、解決策は「もっと頑張れ」ではなく「どのケイパビリティが欠けているか、エージェントにとって読み解けるようにするにはどうすればよいか」を問うことです。 3つのボトルネックを解消した CreaoAIはAI移行前に3つの深刻な問題を抱えていました。 ① プロダクトマネジメントのボトルネック エージェントは2時間でフィーチャーを実装できます。数週間の計画サイクルがボトルネックになります。仕様書レビューではなく、プロトタイプ→リリース→テスト→反復のループで動く必要があります。 ② QAのボトルネック ビルド時間2時間・テスト時間3日では話になりません。AIが書いたコードをAIが構築したテストプラットフォームで検証し、バリデーションを実装と同速度で動かします。 ③ ヘッドカウントのボトルネック 競合は100倍の人員。CreaoAIは25名。採用では追いつけないため、設計で追いつく必要がありました。 アーキテクチャ統合：モノレポへ移行した理由 複数リポジトリにまたがる変更はAIエージェントにとって「不透明」でした。AIは全体像を把握できず、クロスサービスの影響を推論できません。 モノレポへ統合した一番の理由：AIがすべてを見られるようにするため。 ハーネスエンジニアリングの原則では「エージェントが検査・検証・変更できる形にコードを引き込むほどレバレッジが増す」とされる。1週間かけて新設計を策定し、さらに1週間でエージェントを使ってコードベース全体をリアーキテクチャした。 技術スタック詳細 インフラ：AWS 自動スケーリングのコンテナサービスとサーキットブレーカーロールバックで運用。デプロイ後にメトリクスが劣化すると自動でリバートします。CloudWatchを中枢神経系として使い、25以上のアラームとカスタムメトリクスで全サービスから構造化ログを収集します。 CI/CD：GitHub Actions（6フェーズ） 1 Verify CI → Build/Deploy Dev → Test Dev → Deploy Prod → Test Prod → Release CIゲートは型チェック・リント・ユニットテスト・統合テスト・Dockerビルド・Playwright E2Eテスト・環境パリティチェックをすべて必須で実施。手動オーバーライドは存在しない。パイプラインが決定論的であるため、エージェントが結果を予測して障害を推論できる。 AIコードレビュー：Claude Opus 4.6 PRのたびに3つのClaudeレビューパスを並列実行します。 コード品質 — ロジックエラー、パフォーマンス問題、保守性 セキュリティ — 脆弱性スキャン、認証境界チェック、インジェクションリスク 依存関係スキャン — サプライチェーンリスク、バージョン競合、ライセンス問題 1日8回デプロイする状況で人間レビュアーがすべてのPRに集中し続けることは不可能だ。これはサジェスチョンではなくレビューゲートである。 ...

フロントエンドエキスパートの mizchi さんが「チームでの skills 共有に apm いいじゃん。採用」と X にポストして話題になった APM（Agent Package Manager）。Microsoft がオープンソースで開発しているこのツールは、AI エージェントの設定を package.json のように宣言的に管理・共有できます。 APM とは APM は AI エージェント向けの依存関係マネージャーです。npm や pip がライブラリ依存を管理するように、APM はエージェントが必要とするコンテキスト（スキル、プロンプト、プラグイン、MCP サーバーなど）を apm.yml に宣言して管理します。 対応エージェント: GitHub Copilot Claude Code Cursor OpenCode Codex CLI 解決する問題 AI コーディングエージェントを使うには、標準設定・プロンプト・スキル・プラグインといったコンテキストが必要ですが、現状は開発者が各自で手動セットアップしています。移植性がなく、再現性もありません。 APM を使えば、プロジェクトに apm.yml を 1 つ置くだけで、リポジトリをクローンした全員が同じエージェント環境を即座に再現できます。 基本的な使い方 インストール 1 2 3 4 5 6 7 8 # macOS / Linux curl -sSL https://aka.ms/apm-unix | sh # Homebrew brew install microsoft/apm/apm # pip pip install apm-cli apm.yml の設定例 1 2 3 4 5 6 7 8 9 10 11 12 name: your-project version: 1.0.0 dependencies: apm: # 任意のリポジトリからスキルを取得 - anthropics/skills/skills/frontend-design # プラグイン - github/awesome-copilot/plugins/context-engineering # エージェントプリミティブ - github/awesome-copilot/agents/api-architect.agent.md # バージョン指定した APM パッケージ - microsoft/apm-sample-package#v1.0.0 セットアップ 1 2 3 git clone <org/repo> cd <repo> apm install # エージェント設定が一括セットアップされる マーケットプレイスからのインストール 1 2 apm marketplace add github/awesome-copilot apm install azure-cloud-development@awesome-copilot 主な機能 1 つのマニフェストで全対応 apm.yml で以下をすべて管理できます: ...

Anthropic テクニカルスタッフ（Claude Code 担当）の Thariq（@trq212）が公開した記事「Using Claude Code: Session Management & 1M Context」が注目を集めている。「1M トークンのコンテキストウィンドウがあれば大丈夫」という誤解を正し、長いタスクを成功させるカギはコンテキストの能動的な管理にあると明示した内容だ。本記事では、その内容をもとに 5 つのセッション管理手法を整理する。 Context Rot とは何か コンテキストウィンドウとは、モデルが次のレスポンスを生成する際に「見える」すべての情報のことだ。システムプロンプト・会話履歴・ツール呼び出しとその出力・読み込んだファイルがすべて含まれる。Claude Code のコンテキストウィンドウは 100 万トークン。 しかし、コンテキストを使うことには静かなコストがある。それが Context Rot だ。“Rot” は英語で「腐る・朽ちる」を意味する単語で、ソフトウェアの世界では「Bit Rot」や「Code Rot」のように、時間経過や使用とともに静かに劣化していく現象を指す慣用表現として使われる。直訳すれば「コンテキストの腐敗」、意訳すれば「コンテキストの劣化」となる。 コンテキストが増えるにつれてモデルの性能がトークン数に比例して低下する。会話が長くなるほど、モデルの注意力が分散し、古い・無関係なコンテンツが現在のタスクを妨害するようになる。 Context Rot が始まるタイミングはタスクに大きく依存するため固定のルールはないが、長いセッションになるほど確実に忍び寄る。 ターンの終わりは「5択の分岐点」 ここが本質だ。AI が出力を終えるたびに、ユーザーには 5 つの選択肢がある。 選択肢 意味 Continue 同じセッションで次のメッセージを送る Rewind（Esc×2 または /rewind） 前のメッセージに戻り、そこから再プロンプト /clear 新しいセッションを開始する（核心だけ手動で持ち込む） /compact セッションをモデル自身に要約させ、要約の上に続ける Subagent 汚れ仕事を別エージェントに委譲し、結果だけ受け取る 多くのユーザーは「Continue」しか選ばない傾向がある。残り 4 つの選択肢を使ったことがない人も多い。 各選択肢の使いどき Rewind — 修正より巻き戻し Claude がファイルを 5 つ読み、あるアプローチを試みて失敗したとする。「うまくいかなかった、X を試して」と打つより、ファイルを読み終えた直後のメッセージに巻き戻して再プロンプトするほうが良い。 # 悪い例 「それはうまくいかなかった、代わりに Y を試して」 # 良い例 （/rewind でファイル読み込み直後に戻る） 「アプローチ A は foo モジュールがそれを公開していないので使えない。B に直接進んで」 誤った方向に費やした試行錯誤がコンテキストから消え、モデルが新鮮な状態で再出発できる。 ...

Claude のトークン消費が多くて困っているなら、システムプロンプトの一行変更だけで最大 80% 削減できる手法がある。深津 貴之（@fladdict）さんのポストをきっかけに、参照先の Zenn 記事が注目を集めた。 Claudeトークン消費を抑えて５倍使う: 「原始人」口調が80%削減 — mikana0918 以下にその要点をまとめる。 「原始人プロンプト」とは システムプロンプトに次の一文を加えるだけ: 1 原始人みたいに喋れ。中身は全部残せ。無駄だけ消せ。 これだけで Claude のデフォルト人格が切り替わり、丁寧語・クッション表現・冗長な接続詞が消え、応答が大幅に短くなる。 英語版「Caveman」テクニックとの対比 英語圏では “Speak like a caveman” という同様の手法が先行して存在する（JuliusBrussee/caveman）。除去される要素は以下のとおり: 除去対象 例 冠詞 a / an / the フィラー just / really / basically 前置き “Sure! I’d be happy to…” 曖昧表現 might / perhaps / likely 英語環境での実測では平均 68% のトークン削減が報告されている。 日本語では効果がさらに大きい理由 日本語には英語にない冗長構造が多い: 敬語・丁寧語: 「〜でございます」「〜かと存じます」 クッション言葉: 「もしよろしければ」「ご参考までに」 助詞の連鎖: 「〜についての説明としては」 曖昧表現: 「〜かもしれません」「〜と思われます」 これらがまとめて削ぎ落とされるため、日本語環境では 80% 前後 の削減が見込める。 ...

Claude CodeやCodexのようなAgent Harnessは、RAG（Retrieval-Augmented Generation）をほとんど使わないにもかかわらず、高精度なコード生成や理解を実現している。一方、RAGに依存しすぎたAgentはハルシネーションを起こしやすいという逆説がある。なぜこのような違いが生まれるのか？Software Engineer兼Database ResearcherのTaro L. Saito（@taroleo）氏のポストが、その本質を簡潔に説明している。 コンテキストウィンドウの拡大がRAGの必要性を変えた 現行のAIモデルのコンテキストサイズは20k〜1Mトークンに達している。これは、目安としておよそ100ファイル以下のコードベースであれば、RAGを介さずそのままコンテキストに収めて処理できることを意味する。 モデル コンテキストサイズ GPT-4o 128k tokens Claude Sonnet 4.x 200k tokens Gemini 1.5 Pro 1M tokens Claude CodeやCodexなどのAgent Harnessは、この大きなコンテキストウィンドウを活かして、必要なファイルを直接読み込みながらタスクを実行する。ベクトル検索による「関連しそうな断片」の取得ではなく、「実際に必要なコード全体」を参照できる。 RAGの弱点：断片的な情報がハルシネーションを生む RAGは「大量の文書から関連部分を検索して取得する」ことで、LLMに外部知識を与える仕組みだ。ドキュメント検索や広範な知識ベースへのアクセスには有効だが、コードベースのような相互依存が強い構造的情報に対しては課題がある。 RAG特有の問題点： 断片的なコンテキスト: ベクトル類似度で取得したチャンクは、実際の依存関係を無視している場合がある 欠落した情報: 関連するが類似度スコアが低いコードが検索から漏れる 矛盾した断片: 異なるバージョンや関連する別モジュールの断片が混在する こうした不完全な情報でコードを生成させると、存在しない関数を呼び出したり、実際のインターフェースと合わない実装を生成したりするハルシネーションが発生しやすい。 Agent Harnessが「100ファイル以下」で高精度な理由 Claude CodeのようなAgent Harnessが高精度に動く理由は、コンテキストウィンドウの有効活用にある。 プロジェクト構造の把握（ls、find など） 関連ファイルの直接読み込み（cat、read） 完全なコンテキストを持った上でコード生成・編集 RAGのように「類似チャンク」を取得するのではなく、ツールを使って必要なファイルを選択的に読み込むというアプローチだ。ファイル数が100程度であれば、現行のコンテキストサイズに収まるため、コードベース全体を「見た上で」タスクを実行できる。 これにより： 実際に存在する関数・型・インターフェースのみを参照する インポート関係や依存構造を正確に把握する プロジェクト固有の命名規則や設計パターンに従う ベクトル検索が有効なケースと直接読み込みが有効なケース NTT DATAのエンジニアリングブログ「ベクトル検索は不要なのか？」では、生成AI時代にRAGやベクトル検索をどう捉えるべきかを整理している。Taro氏のポストはこの記事を引用しており、「100ファイル以下という目安」はコンテキストサイズとトークン換算から導き出せる経験則だ。 ベクトル検索が有効なケース： 100ファイルを超える大規模コードベース（モノレポ、大企業の内部リポジトリ） 広範なドキュメント検索（社内ナレッジベース、技術文書） リアルタイム情報の取得（外部ドキュメント、最新の仕様） コンテキストに収まる場合に直接読み込みが有効なケース： 中小規模のプロジェクト（スタートアップのコードベース、個人プロジェクト） 特定モジュールへの集中作業 正確な依存関係の把握が必要な場合 RAG自体を強化する方向: GraphRAG という選択肢 「RAGを捨てて直接読み込み」ではなく、「RAGの断片性を補う」方向の研究もある。代表的なのがMicrosoft Researchが2024年に発表した GraphRAG だ。 GraphRAGの基本アイデアは次の通り： ...

Claude Code で動画編集が完全自動化できる「Video Use」が公開されました。browser-use チームが開発したオープンソーススキルです。カメラに向かって話した素材を Claude に渡すだけで final.mp4 が完成します。 Video Use とは Video Use は、Claude Code のスキルとして動作する動画編集自動化ツールです。GitHub リポジトリ browser-use/video-use で公開されており、100% オープンソースで利用できます（ただし ElevenLabs API キーが必要です）。 ブラウザ操作を自動化する browser-use を開発したチームが作成したもので、同じ「LLM に情報を読ませる」思想が動画編集に応用されています。 主な機能 フィラーワード自動カット — 「えー」「あの」「umm」「uh」などの無駄な言葉や、テイク間の無音部分を自動で除去 自動カラーグレーディング — セグメントごとにカラーグレード（ウォームシネマティック、ニュートラルパンチ、カスタム ffmpeg チェーンなど）を適用 字幕自動生成 — デフォルトでは 2 ワードの大文字チャンク形式。スタイルは完全カスタマイズ可能 30ms オーディオフェード — すべてのカット点で自動的に適用され、ポップノイズを防止 アニメーションオーバーレイ — Manim / Remotion / PIL によるアニメーションをサブエージェントで並列生成して追加可能 自己評価ループ — レンダリング後にすべてのカット境界を自動チェック。問題があれば最大 3 回まで自動修正 セッションメモリ — project.md に状態を保存し、次回セッションで継続作業が可能 なぜ LLM で動画編集できるのか Video Use の設計で興味深いのは、LLM は動画を「見ない」 という点です。 Naive approach: 30,000 frames × 1,500 tokens = 45M tokens of noise. Video Use: 12KB text + a handful of PNGs. ...

「ハーネスエンジニアリング」という言葉がAIエージェント界隈でバズワード化し、意味の希薄化が起きている。watany氏のZenn記事「AIエージェントの"ハーネス"に関わる混乱と私見」は、この混乱を「内側のハーネス」と「外側のハーネス」という軸で整理している。本記事は、その整理を元に「ハーネス」という言葉の意味的な分裂を読み解く。 内側のハーネス（Internal Harness） 開発者・プラットフォーム視点の定義。 LangChain: 「エージェント = モデル + ハーネス」という等式を掲げ、自社をハーネス構築のプラットフォームとして位置づける Anthropic: 長時間実行されるLLM処理の仕組みとして定義。ステートレスなモデル呼び出し間でセットアップスクリプトやGitの履歴などのコンテキストを引き継ぐ機構を指す。生成Agentと評価Agentからなる二段階のマルチエージェント構成も含む 内側のハーネスの議論はベンダーロックインを促す傾向があり、プラットフォームとしての優位性を訴求する文脈で使われやすい。 外側のハーネス（External Harness） ユーザー・実践者視点の定義。 Mitchell Hashimoto: 「AIエージェントが同じミスを繰り返さないように設計する」という実践的なアプローチ。開発者の日常的な課題に根ざした定義 OpenAI: メンテナブルで読みやすいエージェント出力の設計を重視し、将来の実行エージェントが参照できる保守可能な成果物の生成を重視する 外側のハーネスはベストプラクティスの共有が主眼で、特定プラットフォームへの依存を前提としない。 なぜ混乱するのか Takuto Wada（@t_wada）氏はこの記事を紹介し、同じ言葉なのにスコープが違うのは言う側のポジションで意味合いがズレているのが理由だと指摘している。 ベンダーは「ハーネス」を自社製品の文脈で語り、実践者は「ハーネス」を運用上の問題解決として語る。どちらも正しい文脈を持ちながら、同一の言葉が異なる聴衆に向けて発信されている。 まとめ 「ハーネス」という言葉を聞いたとき、それが誰の視点からの発言かを意識するだけで、議論の意図がずっと明確になる。 プラットフォーム・フレームワーク文脈 → 内側のハーネス（統合基盤としての役割） 実践・運用文脈 → 外側のハーネス（エラー再発防止・出力品質の設計） AIエージェント開発が加速する中、用語の解像度を上げることは技術コミュニティ全体の生産性に直結する。watany氏の整理は、この問題に対して実践的な視点を提供している。 参考: AIエージェントの"ハーネス"に関わる混乱と私見 — watany (Zenn) t_wada氏のポスト (X)

Anthropic が「Automated Alignment Researchers（AAR）」の研究成果を発表した。Claude Opus 4.6 を使って、AI アライメントの重要課題を自律的に研究させた実験で、9 体の Claude エージェントが人間の研究者を大きく上回る成果を達成した。 スケーラブル・オーバーサイト問題とは 超知能 AI が登場した場合、能力的に劣る人間がどうやって AI を監督するか、という問題が「スケーラブル・オーバーサイト（Scalable Oversight）」だ。この問題に対し、Anthropic は Claude Opus 4.6 を使って自律的に研究させるアプローチを試みた。 実験の設計 具体的には「weak-to-strong supervision（弱から強への監督）」手法を検証した。弱いモデル（Qwen 1.5-0.5B）を教師役として、強いモデル（Qwen 3-4B）を微調整し、強いモデルが本来の性能をどれだけ引き出せるかを測定する。 実験では 9 体の Claude Opus 4.6 エージェントに以下の環境を提供した： サンドボックス環境 共有フォーラム（エージェント間のコミュニケーション） コード保存サーバー スコアリングサーバー 各エージェントには曖昧なヒントのみを渡し、詳細な指示なしで自律的に研究させた。 評価指標：PGR（Performance Gap Recovered） 性能の評価に使われた指標が PGR（Performance Gap Recovered）だ： PGR = 0：弱い教師モデルと同程度の性能しか引き出せなかった PGR = 1：強いモデルの理想的な性能を完全に引き出せた 実験結果 条件 期間 PGR 人間の研究者 2 名 7 日間 0.23 Claude Opus 4.6 × 9 体 5 日間（累計約 800 時間） 0.97 Claude エージェントのコストは約 $18,000（1 AAR 時間あたり約 $22）。7 日かけて PGR 0.23 を達成した人間の研究者に対し、5 日間で PGR 0.97 という圧倒的な成果を出した。 ...

Anthropic が「Claude Code Routines」をリリースした。「時間になったら勝手に動く AI」を、誰でも 24 時間クラウド上で完結させられる仕組みだ。 何が変わったのか これまで AI エージェントを自律実行させるには、PC を常時起動させたり、自前のサーバーを用意したり、cron + スクリプトをハック的に組み合わせる必要があった。Claude Code Routines はこの構成を根本から変える。 セットアップは 2 ステップだけ: プロンプトを設定する リポジトリ・外部連携を接続する これだけで、Anthropic のクラウド上でエージェントが自律的に動作する。 PC つけっぱなし → 不要 自前サーバー → 不要 ハック的な構成 → 不要 完全に「インフラレス運用」が実現した。 トリガー設計 Claude Code Routines の最大の特徴は 柔軟なトリガー設計 にある。 トリガー種別 例 cron 毎朝 9 時に定期レポートを生成 API コール 外部サービスから HTTP リクエストで起動 GitHub イベント PR が開いたら、Issue が立ったら、Webhook が飛んだら これにより、人間が起動操作をしなくてもよくなる。PR を開いた瞬間にコードレビューエージェントが動き出し、Issue が作成されると自動でトリアージが走る、といったワークフローが実現する。 「常駐しないエージェント」という設計思想 Claude Code Routines が体現しているのは、単なる「自動化」ではない。 必要なときだけ AI が “自分で目を覚まし”、処理して、また眠る ...