LLM

Vibe Coding（バイブコーディング）で成果を出せる人と出せない人の違いは何か。CHI 2026 で発表された論文「Computer Science Achievement and Writing Skills Predict Vibe Coding Proficiency」が、その答えを実証的に示している。結論は、CS の基礎知識と論理的な文章作成能力の2つが鍵だというものだ。 Vibe Coding とは Vibe Coding は、2025年初頭に Andrej Karpathy が提唱したプログラミングスタイルだ。ソースコードを直接編集するのではなく、自然言語で LLM にプログラムの仕様を伝える。生成された結果を観察しながら反復的に改善していくアプローチだ。 「誰でも自然言語でアプリが作れる時代」と言われる一方で、実際には同じツールを使っても成果に大きな差が出る。この差を生む要因は何なのか。 論文の概要 Sverrir Thorgeirsson、Theo B. Weidmann、Zhendong Su の3名による研究（arXiv: 2603.14133）は、大学生100名を対象にした事前登録済み（仮説や分析計画を事前に公開した）横断研究だ。 被験者は以下の4つの能力を測定された: コンピュータサイエンス（CS）の達成度 汎用的な認知能力（いわゆる「頭の良さ」） 文章作成能力 Vibe Coding の成績（専門家の合意で設計された評価タスク） 評価タスクでは、参加者はまずサンプルアプリケーションを確認する。次に LLM ベースのエージェントへプロンプトを作成し、生成されたアプリケーションをテストしながら改善を重ねる。最終的な成果物を人間の評価者が採点した。 2つの重要な予測因子 研究の結果、Vibe Coding の成績を有意に予測する因子は以下の2つだった: 1. CS の基礎知識（最も重要） CS の達成度は、汎用的な認知能力を統制した後でも有意な予測因子として残った。つまり、「頭が良い」だけでは不十分で、コンピュータサイエンスの基礎を理解していることが独立した強みになる。 回帰分析の結果、CS の知識が説明する固有分散（ΔR² = 0.125）は文章力（ΔR² = 0.059）の約2倍だった。 2. 論理的な文章作成能力 文章を論理的に構成し、意図を明確に伝える能力も有意な予測因子だった。これは当然とも言える。LLM に的確な指示を出すには、要件を整理し、曖昧さなく文章化するスキルが求められるからだ。 「頭の良さ」だけでは足りない 興味深いのは、汎用的な認知能力（特定分野に依存しない一般的な認知スキル）は、それほど大きな影響を持たなかったという点だ。 これは重要な示唆を含んでいる。Vibe Coding は「誰でもできる」わけではないが、「天才でなければできない」わけでもない。CS の基礎知識と論理的な文章力という、学習可能なスキルが鍵を握っている。 教育・実務への示唆 この研究結果は、AI 時代のプログラミング教育に対して重要な問いを投げかける: ...

Microsoft がオープンソースで公開した Agent Governance Toolkit は、自律型 AI エージェントに欠けていたセキュリティレイヤーを提供するツールキットだ。ポリシー強制、ゼロトラスト ID、実行サンドボックス、信頼性エンジニアリングの4つの柱で、OWASP Agentic Top 10 の全10項目のリスクをカバーする。 背景：なぜ AI エージェントにガバナンスが必要か AI エージェントが自律的にツールを呼び出し、ファイルを操作し、外部 API と通信する時代になった。しかし、その自律性にはリスクが伴う。意図しないゴールの書き換え、過剰な権限の付与、エージェント間通信の改ざん、カスケード障害など、従来の Web アプリケーションとは異なるセキュリティ課題がある。 OWASP は「Agentic Top 10」として AI エージェント特有のリスクを定義しており、Agent Governance Toolkit はこの全10項目に対応している。 4つの柱 1. Policy Engine（ポリシーエンジン） すべてのエージェントアクションを実行前に評価し、許可・拒否を判定する。サブミリ秒（0.1ms 未満）のレイテンシで動作するため、エージェントの応答速度に影響を与えない。 1 2 3 4 5 6 from agent_governance_toolkit import CapabilityModel capabilities = CapabilityModel( allowed_tools=["web_search", "file_read"], denied_tools=["file_write", "shell_exec"] ) 許可するツールと拒否するツールを明示的に定義し、エージェントが意図しない操作を行うことを防ぐ。 ...

Agentic Coding（AIエージェントによるコーディング）が普及する中、AIに渡すドキュメントをどこに配置すべきかという問題が注目されています。古川陽介氏（@yosuke_furukawa）のポストで紹介されていた記事「Your Docs Directory Is Doomed」（Yagmin）の内容をもとに、この問題を考えます。 /docs ディレクトリの進化と限界 Agentic Coding を始めると、多くのプロジェクトで以下のようなドキュメントが増えていきます: まず CLAUDE.md や AGENTS.md のような設定ファイルを作成 ARCHITECTURE.md でシステム全体の構造を記述 機能仕様やデザインドキュメントを /docs フォルダにまとめ始める この流れ自体は自然ですが、記事では /docs ディレクトリへの集約には根本的な問題があると指摘しています。 /docs ディレクトリの問題点 1. 発見可能性（Discoverability） LLM はどのドキュメントをいつ読むべきかを自律的に判断する必要があります。/docs に大量のファイルがある場合、LLM が適切なドキュメントを見つけられる保証はありません。計画フェーズで必要なドキュメントと、コード生成フェーズで必要なドキュメントは異なりますが、それを正しく参照できるでしょうか。 2. ドキュメントの腐敗（Documentation Rot） コードは頻繁に変更されますが、対応するドキュメントの更新は忘れがちです。小さな不整合が積み重なり、LLM が参照するコンテキストの品質が徐々に劣化していきます。さらに厄介なのは、ドキュメントが間違っていることに気づくための仕組み（observability）がないことです。 3. 構造の欠如 ドキュメント間の階層関係や依存関係が明示されていないため、LLM がドキュメント群をナビゲートする明確な方法がありません。各自が自分のスタイルで書くため、LLM にとって情報の探索がしにくい構造になります。 4. 変更速度の不一致（Velocity Mismatch） ドキュメントの種類によって変更頻度が異なります。アーキテクチャの概要はめったに変わりませんが、API仕様やコンポーネントの詳細は頻繁に更新されます。一つのディレクトリにすべてをまとめると、この違いが管理を困難にします。 コロケーション（Colocation）というアプローチ 古川氏がツイートで触れているように、一つの解決策はコロケーション — ドキュメントをコードの近くに直接配置する方法です。 src/ auth/ README.md # 認証モジュールの説明 auth.ts auth.test.ts api/ README.md # APIモジュールの説明 routes.ts middleware.ts このアプローチの利点: 発見可能性の向上: 関連コードと同じディレクトリにあるため、LLM が自然に参照できる 更新の同期: コードを変更する際にドキュメントも目に入るため、更新忘れが減る スコープの明確化: 各ドキュメントが担当する範囲が明確 Agentic Coding でのドキュメント管理の方向性 「Your Docs Directory Is Doomed」の記事は、従来のドキュメント管理は「1985年からの解決策」に過ぎないと指摘しています。Agentic Coding 時代には、以下の要素が重要になります: ...

DX 社の Deputy CTO である Justin Reock 氏が、400社のデータを分析した結果を公開しました。AI コーディングツールの導入による開発者の生産性向上は、ベンダーが謳う「2〜3倍」や「10倍」ではなく、約10% にとどまるという内容です。 調査の概要 DX 社は 2024年11月から2026年2月にかけて、400社のエンジニアリング組織を対象に、AI ツールの利用状況と PR（Pull Request）スループットの相関を分析しました。 主な結果: AI ツールの利用率は平均 65%増加 PR スループットは 9.97%（約10%）の増加 にとどまった 大半の組織は 8〜12% の範囲に収まった なお、PR 目標値を設定しているチーム（メトリクスのインフレーションが起きやすい）は分析から除外されています。 なぜ10倍にならないのか 開発者へのインタビューから浮かび上がった根本的な理由は、「コードを書くこと自体がボトルネックではなかった」 という点です。 あるシニア開発者のコメント: 簡単なタスクは少し楽になった。4日かかるタスクが3日になるかもしれない。でも、それは PR を3倍出せるという意味ではない。 ソフトウェア開発のライフサイクル全体を考えると、コーディングはその一部に過ぎません: 要件の理解・すり合わせ — AI では圧縮しにくい コードレビュー — 人間同士のコミュニケーションが必要 テスト・デプロイ — 組織のプロセスに依存 チーム間の調整・ハンドオフ — 人間中心の活動 AI ツールがコーディング速度を50%向上させたとしても、コーディングが全体の15%しか占めていなければ、全体への影響は限定的です。 10%でも価値はある 記事では、10%の生産性向上を過小評価すべきではないとも指摘しています。 500人の開発者がいる組織なら、50人分の追加アウトプット に相当 採用コストなしでその効果が得られる 組織全体で一貫して得られる改善は意味がある エンジニアリングリーダーへの示唆 この調査結果は、AI ツール導入における期待値の設定が重要であることを示しています: 現実的な目標設定: 10倍ではなく10%の改善を前提に ROI を計算する ボトルネックの正確な把握: コーディング以外のプロセス（レビュー、テスト、調整）にも目を向ける ベンダーの主張を鵜呑みにしない: マーケティング上の数字と実測値には大きな乖離がある 参考 AI productivity gains are 10%, not 10x — Justin Reock (DX Newsletter) 元ポスト — Haruki Yano (@harumak_11)

動画編集者のカズマル氏（株式会社ブイスト）が、300日以上かけて50種類以上のAIツールに500万円以上を課金して検証した「AI動画編集 自動化のカラクリ」が話題になっている。AIによる自動カットと自動テロップで、動画編集のワークフローがどう変わるのかを整理する。 AI動画編集が解決する2つの課題 動画編集で最も時間がかかる作業は、大きく2つに分けられる： カット編集 — 無音部分、言い淀み、NGテイクの除去 テロップ作成 — 字幕・キャプションの生成と配置 従来これらは手作業で行うしかなく、30分のインタビュー動画であればテロップ作成だけで2時間以上かかることも珍しくなかった。AIツールの登場により、これらの作業が大幅に自動化されつつある。 自動カットの仕組み AIによる自動カットは、主に音声波形解析と無音区間検出で実現されている。 代表的なアプローチ 無音区間の自動検出・削除: 音声波形から無音部分を特定し、ワンクリックで除去 フィラーワード検出: 「えーと」「あのー」など不要な言い淀みを音声認識で検出して除去 ジャンプカット生成: 不要な間を詰めた際の映像の不自然さを、自動ズーム・パンで軽減 実務での注意点 感度設定が重要で、高すぎると必要な「間」までカットされてしまう。プレビューで確認しながらの調整が必須だ。 自動テロップの仕組み 音声認識（STT: Speech-to-Text）技術を使い、動画内の音声を自動で文字起こしして字幕化する。 最新のAI文字起こし精度 2026年現在、日本語の音声認識精度は飛躍的に向上しており、実用レベルに達している。多くのツールが100言語以上に対応し、翻訳字幕の自動生成も可能になっている。 テロップ作成の効率化 手動でテロップを作成する場合と比較して、最大90%以上の時間短縮が見込める。30分のインタビュー動画であれば、通常2時間以上かかるテロップ作成が数分〜15分程度で完了する。 主要なAI動画編集ツール Vrew（ブリュー） 韓国Voyager X社が開発したオールインワンAIビデオエディター。 音声認識ベースの編集: 動画の音声を自動で文字起こしし、テキストベースで編集可能 無音区間の自動削除: ワンクリックで無音部分を検出・削除 テキスト編集＝映像編集: 文字起こしテキストの不要部分を削除すると、対応する映像も自動カット 無料プランあり Adobe Premiere Pro プロ向け動画編集ソフトにもAI機能が搭載されている。 シーン編集検出: AIが自動的にシーン境界を検出してカット 自動文字起こし: 音声からキャプションを自動生成 カラーマッチ: 異なるシーンの色合いをAIで自動調整 OpusClip 長尺動画からショート動画を自動生成するクラウドサービス。 見どころの自動抽出: AIが重要なセグメントを検出してダイジェスト動画を生成 自動字幕生成: 多言語対応・翻訳機能付き ノイズ除去: AI音声エンハンス機能 PowerDirector CyberLink社のAI搭載動画編集ソフト。 AI音声読み上げ: テキストから音声を自動生成 AI背景除去・自動顔ぼかし: 映像加工の自動化 AIノイズ除去: 音声品質の向上 500万円の課金検証から見えるもの カズマル氏のように大量のツールを実際に業務で検証することで見えてくるのは、単一のツールで完結するケースは少ないということだ。実務では複数のツールを組み合わせたワークフローが必要になる。 一般的なAI動画編集ワークフロー 素材撮影 → AIで無音カット → AI文字起こし → テロップ調整 → 最終編集 （Vrew等） （Vrew/Premiere） （手動微調整） （Premiere等） 重要なのは、AIは「完全自動化」ではなく「大幅な時短」を実現するツールだという点だ。最終的な品質チェックと微調整は人間の判断が必要になる。 ...

Claude Code をローカルLLM（llama.cpp、Ollama など）で使う際に、毎回プロンプト処理に異常な時間がかかるという問題が報告されています。原因は Claude Code が付加する「Attribution Header」によるKVキャッシュの無効化です。設定一つで解決できるので、対処法をまとめます。 何が起きているのか Claude Code v2.1.36 以降、リクエストごとに以下のような Attribution Header がプロンプトの先頭に付加されるようになりました。 x-anthropic-billing-header: cc_version=xxxx; cc_entrypoint=cli; cch=xxxx; この cch の値がリクエストのたびに変化します。ローカルLLMサーバー（llama.cpp、Ollama、LM Studio など）はプロンプトの先頭からバイト単位で一致した部分までKVキャッシュを再利用する仕組みのため、先頭が毎回変わるとキャッシュが丸ごと無効化されます。 結果として、数万トークンのシステムプロンプトや会話履歴を毎回ゼロから処理することになり、推論速度が最大90%低下するという報告があります。 対策：Attribution Header を無効化する ~/.claude/settings.json の env セクションに以下を追加します。 1 2 3 4 5 { "env": { "CLAUDE_CODE_ATTRIBUTION_HEADER": "0" } } 既に settings.json がある場合は env セクション内にキーを追加してください。 注意点 export CLAUDE_CODE_ATTRIBUTION_HEADER=0 ではダメ。シェルの環境変数として設定しても反映されません。必ず settings.json 経由で設定します ついでに不要なテレメトリも無効化しておくと、余計な通信を減らせます 1 2 3 4 5 6 7 { "env": { "CLAUDE_CODE_ATTRIBUTION_HEADER": "0", "CLAUDE_CODE_ENABLE_TELEMETRY": "0", "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1" } } KVキャッシュの仕組みをおさらい ローカルLLMサーバーが採用している Prefix Caching（Automatic Prefix Caching）は、プロンプトの先頭から連続して一致するトークン列のKV（Key-Value）テンソルを再利用する仕組みです。 ...

Andrej Karpathy が2026年3月に公開した autoresearch は、AIエージェントにLLMのトレーニングを丸投げするツールだ。GPU1台・一晩放置するだけで、エージェントが自律的にコード修正→実験→評価を繰り返し、人間の研究者なしで性能を改善していく。 実際に Karpathy 自身が約700回の実験を実行したところ、GPT-2の学習時間が2.02時間→1.80時間へ11%短縮された。さらに別の開発者は、8時間・37実験で0.8Bモデルが従来の1.6Bモデルを19%上回るスコアを叩き出している。 autoresearch の仕組み autoresearch はわずか630行のPythonで構成されており、3つのコアファイルで動作する。 3つのコンポーネント ファイル 役割 編集者 program.md エージェントへの指示書（戦略・ルール・評価基準） 人間 prepare.py データ準備・トークナイザー・評価関数（固定） 変更禁止 train.py モデル・オプティマイザ・学習ループ AIエージェント エージェントループ エージェントは以下のサイクルを自動で繰り返す: program.md を読んで戦略を把握 train.py を修正（アーキテクチャ変更、ハイパーパラメータ調整など） 5分間の固定時間でトレーニングを実行 val_bpb（検証ビット/バイト）が改善したか確認 改善 → 変更を保持、悪化 → 変更を破棄 1に戻る 5分の固定時間予算により、1時間あたり約12実験、一晩（8時間）で約100実験が可能になる。 実験結果 Karpathy 自身の実験 Karpathy は自身の nanochat（GPT-2トレーニング環境）に autoresearch を適用: 約700回の実験を2日間で実行 約20個の実質的な改善を発見 GPT-2到達時間: 2.02時間 → 1.80時間（11%短縮） 発見された改善の例: バッチサイズの半減（5分以内のステップ数増加） モデル深度の調整（depth 9への最適化） スライディングウィンドウ比率のチューニング コミュニティの成果 GitHub Discussions で報告された改善: Discussion #32: val_bpb を 0.9979 → 0.9773 に改善（89実験、H100 80GB） Discussion #43: val_bpb を 0.9979 → 0.9697 に改善（126実験、H100 80GB） Tobi のケース: 0.8Bモデルが従来の1.6Bモデルを 19%上回るスコア（37実験、8時間） 使用されるLLM autoresearch のエージェントとして動作するLLM自体は外部モデルを使用する。Karpathy のテストでは Claude や GPT 系モデルが使われている。 ...

AIエージェントが単独で動く時代から、複数のエージェントが協調して動く時代へ移行しつつある。エージェント間の通信を設計するとき、「会話（何を話すか）」と「transport（どう届けるか）」を分離する考え方が重要になっている。本記事では、2026年に整備が進むエージェント間通信プロトコルの全体像と、Relay基盤のアーキテクチャを整理する。 なぜ「会話」と「transport」を分離するのか AIエージェント同士が会話する際、2つの関心事が混在しがちだ: 会話層: タスクの依頼、進捗報告、結果の返却といった「意味のあるやりとり」 transport層: HTTP、gRPC、WebSocket、SSE といった「届ける仕組み」 これらを密結合にすると、transport を変更するたびに会話ロジックを書き直す必要が生じる。たとえば、開発時は HTTP で通信していたエージェントを、本番では gRPC に切り替えたいケースや、ローカルの関数呼び出しからリモートの API 呼び出しに切り替えたいケースがある。 分離することで、エージェントのビジネスロジック（会話）は transport に依存せず、transport の差し替えが容易になる。 2026年のエージェント間通信プロトコル 現在、エージェント通信の標準化が急速に進んでいる。主要なプロトコルは以下の通り。 MCP（Model Context Protocol） Anthropic が策定したプロトコルで、エージェントと外部ツール/リソースの接続を標準化する。API、ファイルシステム、データベースへのアクセスを統一的なインターフェースで提供する。 役割: ツール・コンテキスト層 transport: RESTful サーバー経由の構造化データ交換 エージェント → MCP サーバー → 外部ツール（DB, API, ファイル） A2A（Agent-to-Agent Protocol） Google が主導し、50社以上のパートナーが参加するオープン標準。エージェント同士のピアツーピア通信とタスク委譲を実現する。 役割: エージェント間通信層 transport: HTTPS 上の JSON-RPC 2.0 + SSE（ストリーミング） 通信モデル: クライアントエージェント → リモートエージェント クライアントエージェント ──JSON-RPC──→ リモートエージェント ←──SSE──── A2A の特徴は、エージェントの内部メモリ、ツール、ロジックを共有せずに協調できる点。発見（Discovery）→ 認可（Authorization）→ 通信（Communication）の3段階で動作する。 ACP（Agent Communication Platform） REST ベースの通信とエージェントレジストリを組み合わせたプラットフォーム。 役割: レジストリ駆動の通信基盤 transport: REST インターフェース 特徴: ステートフルなメッセージルーティングでコンテキストを保持 ANP（Agent Network Protocol） インターネット規模のエージェント協調を想定したプロトコル。 ...

SEO・コンテンツマーケティングの専門家 Jake Ward 氏が、AI とプログラマティック SEO を組み合わせて 60日間で SEO トラフィックを466%（5.7倍）増加 させた手法が注目を集めています。13,000ページ以上をわずか3時間で生成し、週間オーガニッククリックを971から5,500に伸ばした具体的なアプローチを解説します。 成果の概要 13,000+ ページを3時間で生成 週間オーガニッククリック: 971 → 5,500（+466%） 60日間で達成 従来のプログラマティック SEO との違い 従来のプログラマティック SEO は、テンプレートの単語を置換するだけのものが多く、低品質なページが量産される問題がありました。Jake Ward 氏のアプローチは、AI にフリーフォームでコンテンツを書かせるのではなく、厳密な JSON Schema を埋め込むことで品質を担保しています。 3つの核心ポイント 1. JSON Schema によるコンテンツ構造化 最も重要な技術的要素が、AI への指示に厳密な JSON Schema を使うことです。 1 2 3 4 5 6 7 8 9 10 11 12 13 { "section_title": "string", "items": [ { "name": "string", "description": "string (50-100 words)", "difficulty_level": "beginner | intermediate | advanced", "potential_score": "number (1-10)" } ], "min_items": 15, "max_items": 20 } AI にフリーフォームの文章を書かせると、ページごとに品質がばらつきます。JSON Schema で出力形式を固定することで、13,000ページ全体で一貫した品質を維持できます。 ...

LLMベースのコーディングエージェント（Claude Code、Cursor など）は、セッションが変わるたびにプロジェクトの規約や過去のミスを忘れてしまう。小さなプロトタイプなら問題にならないが、10万行を超える大規模コードベースでは「毎回同じ説明をする」「直したはずのバグパターンが再発する」といったコストが無視できなくなる。 2026年2月に公開された論文 Codified Context: Infrastructure for AI Agents in a Complex Codebase（Aristidis Vasilopoulos）は、この問題に対して 3層のメモリインフラストラクチャ を提案し、108,000行のC#分散システムを283セッションかけて構築した実践データとともに検証している。 問題：セッション間で失われる記憶 LLMエージェントは各セッションの開始時にコンテキストがリセットされる。.cursorrules や CLAUDE.md のような単一ファイルでプロジェクト規約を伝える方法は小規模なら有効だが、10万行規模のシステムでは単一プロンプトに収まりきらない。 結果として起きる典型的な問題: 命名規則やアーキテクチャパターンの逸脱 過去に修正した失敗パターンの再発 サブシステム間の整合性の欠如 提案手法：3層の Codified Context 論文では、プロジェクト知識を 負荷分散インフラストラクチャ として扱う3層アーキテクチャを提案している。 Tier 1: Hot-Memory Constitution（約660行） 常にセッションにロードされるMarkdownファイル。以下を含む: コード品質基準・命名規則 ビルドコマンド アーキテクチャパターンの要約 よくある操作のチェックリスト 既知の失敗モード（過去のバグパターン） オーケストレーション用トリガーテーブル トリガーテーブルは「どのファイルを変更したら、どの専門エージェントを呼ぶか」を定義する: ファイル変更 割り当てエージェント Network, sync network-protocol-designer Coordinates, camera coordinate-wizard UI配信 ui-sync-specialist Tier 2: Specialized Agents（19エージェント、約9,300行） タスクに応じて呼び出される専門エージェント群。2つのクラスに分かれる: 高能力エージェント（8個、平均711行）: ネットワークプロトコル設計、アーキテクチャ検証、デバッグなど 標準能力エージェント（11個、平均327行）: 特定タスクにフォーカス 各エージェント仕様の 50%以上がプロジェクト固有のドメイン知識 で構成されている。コード例、数式、失敗モードなど、そのプロジェクトでしか使えない具体的な情報が埋め込まれている点が特徴。 Tier 3: Cold-Memory Knowledge Base（34文書、約16,250行） サブシステムごとの詳細仕様をMarkdownで記述し、MCP（Model Context Protocol）検索サーバー経由でオンデマンド参照する: ...