OTR_FrameworkLearningSupplyDemand

標準化フレームワークの習得の需給とコーディング・エージェント

• TOP > マーケティング > 標準化フレームワークの習得の需給とコーディング・エージェント

概要

Open 棟梁に限らず、標準化カスタム・フレームワーク（開発基盤）には、昔から 2 つの弱点があった。

• 質が低いものが多い。
  Open 棟梁は、展開数と OSS 化によって、この問題を相対的には解決している。
• 技術者に習得を敬遠される。
  汎用フレームワーク（ランタイム・フレームワーク）と違い、他の案件で出会う確率（エンカウント率）が低い。
  覚えても他案件で役立て難いので、技術者にとって割に合わない。

一方で、「解空間を狭めスロットを埋める作業に近づける」効果（コーディング・エージェント時代の開発基盤）は、案件にとって重要である。
つまり、この敬遠は、ある意味、需給の問題だった。案件（需要側）は標準化を必要とし、技術者（供給側）は習得したがらない。

コーディング・エージェントは、この需給を大きく変える可能性がある。

• 習得する主体が変わる：スロットを埋めるのがエージェントになる。エージェントには、エンカウント率によるキャリア上の損得が無い。
• 習得コストの形が変わる：人の学習時間から、リポジトリに置いた方式（AGENTS.md・スキル）の読み込みに変わり、毎回ほぼ同じ形で再現できる。
• 習得したものの価値が変わる：方式を決め、書き出し、検証するリードエンジニアの経験は、フレームワークに依らず持ち運べるスキルになる。

ただし、外部の調査を見ると、エージェントも、学習データに少ない固有の API は苦手である。
需給が改善するのは、方式が書き出され、固有 API の面が小さく、検証の仕組みがある場合に限られる。
以下では、この可能性と条件を、いくつかの角度から整理する。

詳細

従来の需給の構造

立場	標準化フレームワークに対する見方
案件・組織（需要側）	方式が揃い、品質と生産性が揃う。要員が入れ替わっても同じ形で作れる（開発基盤のKPIとKGI）
技術者（供給側）	習得コストに対して、再利用の機会（エンカウント率）が低い。ランタイム・フレームワーク（ASP.NET など）のスキルの方が、市場価値になる

• 技術者の投資判断は、おおよそ「習得コスト × 再利用の機会」で決まる。標準化フレームワークは、後者が小さい。
• 組織間を移動する個人（SES・派遣・個人事業主）ほど、この傾向は強い（開発基盤を横展開する際の課題の「個人と組織」）。
• 質の低いフレームワークは、「習得した上に損をする」ので、敬遠を強める。
• Open 棟梁では、この需給の差を、次の分担で凌いできた（営業コンテンツの「習得について」）。
  • リードエンジニアが習得して、プロジェクト・テンプレートを作る。
  • 開発者は、画面と DBMS の間の項目移送を実装するレベルのスキルで開発できるようにする。
• それでも、案件ごと・要員ごとに、方式の教育とレビューのコストは残っていた。

角度 1：習得の主体が変わる

• スロットを埋める作業をエージェントが行うと、「誰が覚えるか」が人からエージェントに移る。
• エージェントには、キャリアも、他案件での再利用の損得も無い。セッションごとに方式を読み込み直し、そのとおりに書く。
• 習得コストは、人の学習時間（日・週単位）から、コンテキストに載せる文書の量（トークン）に変わる。
  要員の入れ替わりのたびに教育し直す必要も無い。
• 人の開発者の役割は、書く人から検証する人へ寄る。
  スロットが決まっていれば、「スロットの外に書いていないか」で方式違反を判断できる（コーディング・エージェント時代の開発基盤）。

角度 2：エージェントも固有の API は苦手（外部の調査）

エンカウント率の問題は、エージェントにも「学習データ上の出現頻度」という形で存在する。

調査	結果
Huawei の産業研究（arXiv 2505.05057）	API の幻覚（存在しない・誤った API 呼び出し）の率は、サードパーティのライブラリで約 13％、プロジェクト固有の API で約 85％（4 モデル平均、200 スニペット）
CloudAPIBench（Amazon、arXiv 2407.09726）	公開コードでの出現頻度が低い API ほど誤る。GPT-4o の正しい呼び出しは約 39％で、API 文書を検索して与えても約 48％
PriCoder（arXiv 2603.15159）	プライベート・ライブラリの API 文書を正しく与えても、LLM はまだ上手く呼び出せない

• つまり、何もしなければ、標準化フレームワークは人にとってもエージェントにとっても「覚えにくい」。
• 文書を渡すだけでは足りない。次の 2 つが効く、と考えられる（調査結果からの推論）。
  • 固有 API の面を小さくする：Open 棟梁では、開発者が触る固有 API が、UOC_ メソッド・引数クラス・DoBusinessLogic などに限られる。
    解空間を狭めることは、エージェントが正しく呼ぶべき固有 API を減らすことでもある。
  • 真似る具体例を置く：サンプル・プロジェクト・テンプレートと、スキル内のコード例。
• なお、Open 棟梁は 2014 年から GitHub で公開しているので、学習データに含まれている可能性はある。ただし確認はできないので、それに頼らない。

角度 3：方式の書き出し方（コンテキスト・ファイルの研究）

• ETH Zurich の研究（arXiv 2602.11988、2026-02）は、リポジトリの AGENTS.md などのコンテキスト・ファイルの効果を測った。
  • LLM に生成させたファイルは、タスクの成功率をわずかに下げ（SWE-bench Lite で約 0.5％、AgentBench で約 2％）、推論コストを 20％以上上げた。
  • 人が書いたファイルは、成功率をわずかに上げた（AgentBench で平均約 4％）が、手順とコストは増えた。
  • 著者は、人が書くファイルを最小限の要件に留めることを勧めている。
• ここから言えるのは、量を書けばよいわけではないということである。
  • 常にコンテキストに載せるもの（AGENTS.md）は、概要と規約に絞る。
  • 具体的なコードの書き方は、必要なときだけ読まれるスキルに分ける。
• OpenTouryoCodingAgentAssets は、この形になっている。
  インストラクション（常時載る）とスキル（44 個。B 層・D 層・P 層・例外・トランザクションなど、必要なときだけ読まれる）に分けている。
• ただし、この研究は汎用 OSS のバグ修正（SWE-bench 等）で測ったもので、フレームワークのスロットを埋める作業にそのまま当てはまるかは分からない。

角度 4：方式とノウハウの可搬性

• Anthropic は 2025-12 に、スキルの形式（SKILL.md）を Agent Skills のオープン標準として公開した。
  Claude Code・Codex・GitHub Copilot など、多くのツールが同じ形式を読む（ツールごとの差はある）。
• これにより、フレームワークの知識が、人ではなくリポジトリとスキルに乗って移動する。
  • 従来は、習得者が案件を離れると、ノウハウも一緒に抜けた（エンカウント率の問題の裏返し）。
  • 今は、スキルを導入スクリプトで案件に持ち込める（OpenTouryoCodingAgentAssets の install.ps1）。
• 供給側の損得も変わる。
  • 標準化フレームワークの「使い方」は持ち運べないが、方式を決め、書き出し、エージェントに埋めさせ、検証する経験は持ち運べる。
  • これは、他のフレームワークにも、SoE・SoI の領域にも使える（ソリューション提供のサポート）。
    纏め者・リードエンジニアの経験が、市場価値のあるスキルになる。

角度 5：人の側の習得（逆方向の証拠）

エージェントに任せるほど、人は覚えなくなる。これは利点でもあり、危険でもある。

• Anthropic のランダム化比較試験（arXiv 2601.20245、2026-01）
  • 52 人の技術者が、未経験の Python ライブラリ（Trio）を AI あり／なしで学んだ。
  • AI ありの群は、理解度テストの点が低かった（報道では 50％ 対 67％）。差はデバッグの問題で最も大きかった。作業時間の短縮は有意ではなかった。
  • コード生成を丸ごと任せた人ほど、理解が落ちた。一方、質問しながら使う形では、理解は保たれた。
• METR のランダム化比較試験（2025-07）
  • 熟練した開発者が、よく知っている自分のリポジトリで作業すると、AI ありの方が 19％遅かった。本人は 20％速くなったと感じていた。
  • 理由の 1 つは、「方向は合っているが、求めるものと少し違う」出力のレビューと修正に時間を取られたことである。
• ここから言えること（推論）
  • 開発者がフレームワークを覚えなくてよくなる一方、検証できる人がいなくなる危険がある。
    リードエンジニア・纏め者は、引き続きフレームワークを理解している必要がある。覚える人を絞れる、ということである。
  • 「方向は合っているが少し違う」出力を減らすことは、まさに解空間を狭める効果である。
    方式が先に決まっていれば、レビューは「方式どおりか」の確認に寄る。
• 未知のコードベースへの立ち上がり（オンボーディング）を AI が短くするかについては、厳密な計測はまだ無い。
  定性的には、未知の技術スタックの初期の摩擦を AI が和らげた、という報告がある（arXiv 2507.00788）。

角度 6：信頼と検証

• Stack Overflow の 2025 年の開発者調査では、AI の出力の正確さを信頼しない開発者が 46％（前年 31％）に増えた。
  AI エージェントを使っている開発者は約 31％だった。
• 出力を信頼できないなら、検証のしやすさの価値が上がる。
  • 構造が決まっていれば、どこを見ればよいかが決まる。
  • Open 棟梁では、ビルド・全テスト・スモークテストのスクリプトで検証する（リリース・エンジニアリング）。
  • 版の違いは、タグ間の差分から作った詳細なリリース情報で追える。エージェントにバージョンアップを任せるときの入力になる。

角度 7：汎用フレームワーク側の同じ議論

• Ruby on Rails は、「規約（名前・フォルダ・コマンド・パターン）が揃っているので、少ない指示で、Rails らしい変更になりやすい」と AI 向けのページで述べている。
  実務者からも、「アーキテクチャのドリフトが減る」という声がある。
• これは、Open 棟梁の「解空間を狭める」と同じ主張を、汎用フレームワークの側から言っている。
• 違いは、Rails の規約は学習データに大量にある（エンカウント率が高い）のに対し、
  標準化フレームワークの規約は、スキルとして明示的に渡す必要があることである（角度 2）。
• なお、規約の強いフレームワークの方がエージェントの出力が良い、という比較実験は、見つからなかった。

需給はどう変わるか

観点	従来（人が実装）	エージェントが実装
誰が習得するか	開発者全員（少なくとも一部）	リードエンジニア・纏め者と、エージェント
習得コスト	要員ごとの学習・教育（日・週単位）	方式の書き出しは一度。読み込みは毎回ほぼ無償
再利用の機会	低い（エンカウント率の問題）	エージェントには損得が無い。人の側は、方式を書き出す経験として持ち運べる
ノウハウの所在	人（離任で抜ける）	リポジトリ・スキル（案件に持ち込める）
質の問題	習得者が損をする	エージェントが質の低い方式をそのまま増幅する。質の重要性はむしろ上がる
ボトルネック	開発者の習得と教育	方式を決め、書き出し、検証するリードエンジニアの供給

• ボトルネックは消えずに、リードエンジニアの供給へ移る。
  これは、開発基盤を横展開する際の課題の「残る課題」と同じである。

需給が改善する条件と、Open 棟梁での対応

条件	Open 棟梁での対応
方式が書き出されている	OpenTouryo の AGENTS.md・CODING.md・ANALYSIS.md、OpenTouryoCodingAgentAssets のインストラクションとスキル
常に載せる文書が小さい	インストラクション（概要・規約）と、必要なときだけ読まれるスキルに分けている
固有 API の面が小さい	P・B・D 層のスロット（UOC_ メソッドなど）。共通処理は親クラスとフレームワークが持つ
真似る具体例がある	サンプル・プロジェクト・テンプレート、セットアップと変形のスキル（新規プロジェクトのセットアップ）
検証できる	ビルド・テスト・スモークテストのスクリプト、方式に沿っているかを見るレビュー
版の変化を追える	詳細なリリース情報（タグ間の差分から）、バージョンアップの進め方
フレームワークの質	2007 年以来の展開、2014 年からの OSS 化、継続的な保守
理解している人がいる	リードエンジニア・纏め者（ソリューション提供のサポートの役割分担）

訴求メッセージへの反映（案）

• 「標準化の効果はそのままに、覚える人を絞れる」
  開発者全員が覚えなくても、エージェントが方式どおりに書く。覚えるのは、方式を決めて検証する人である。
• 「ノウハウは、人ではなくリポジトリに残る」
  方式は、AGENTS.md とスキルとして案件に持ち込める。要員が替わっても失われない。
• 「纏め者の経験は、持ち運べるスキルになる」
  方式を決め、書き出し、エージェントに埋めさせ、検証する経験は、フレームワークや領域を越えて使える。

上記の外部の調査は、いずれも Open 棟梁を対象にしたものではなく、汎用的な条件で測ったものである。
Open 棟梁の案件での効果（例：立ち上げ期間、レビュー指摘のうち方式違反の割合、要員交代時の立ち上がり）は、
実際のソリューション提供の中で計測していく（開発基盤のKPIとKGI）。

参考

当 Wiki

• コーディング・エージェント時代の開発基盤
• ソリューション提供のサポート
• 開発基盤を横展開する際の課題
• ランタイム・フレームワーク
• 営業コンテンツ

外部の調査（2026-10 時点で参照）

• 固有 API・低頻度 API
  • Towards Mitigating API Hallucination in Code Generated by LLMs with Hierarchical Dependency Aware（arXiv 2505.05057）
  • On Mitigating Code LLM Hallucinations with API Documentation（arXiv 2407.09726）
  • PriCoder（arXiv 2603.15159）
  • Private-Library-Oriented Code Generation with Large Language Models（arXiv 2307.15370）
• コンテキスト・ファイル
  • Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?（arXiv 2602.11988）
• スキルの標準
  • Agent Skills（agentskills.io）
• 人の側の習得・生産性
  • How AI assistance impacts the formation of coding skills - Anthropic（arXiv 2601.20245）
  • METR's study on how AI affects developer productivity（DX による METR の調査の解説）
  • Echoes of AI: Investigating the Downstream Effects of AI Assistants on Software Maintainability（arXiv 2507.00788）
• 信頼
  • Stack Overflow's 2025 Developer Survey
• 汎用フレームワーク側の議論
  • Rails and AI - rubyonrails.org

---

Tags: 再構築