Skip to content

OTR_CodingAgentAndDevInfra

nishi_74322014 edited this page Oct 28, 2026 · 2 revisions

コーディング・エージェント時代の開発基盤

概要

Open 棟梁のマーケティングの中心となる主張を纏める。

  • 開発基盤は、実装者が書くべき場所と書き方を事前に決めて、解空間を狭める。
  • 解空間が狭まると、実装は「決められた枠(スロット)に業務ロジックを埋める作業」に近づく。
  • これは、コーディング・エージェント登場以前、人間が実装していた頃から変わっていない。
    人間向けに作った標準化の仕組みが、そのままコーディング・エージェントにも効く。

詳細

解空間を狭めるとは

フレームワーク無しで「この画面を作って」と依頼すると、実装の選択肢はほぼ無制限になる。

  • レイヤの切り方、トランザクションの掛け方、例外の扱い、ログの出し方、SQL の書き方、…
  • 実装者ごとに答えが変わり、その差がそのまま品質のバラツキになる。

開発基盤は、これらを先に決めておく。

決めておくもの Open 棟梁での実体
アプリケーションの構造 P・B・D 層の論理 3 層構成
共通処理の置き場所 ベースクラス1・2(制御の反転(IoC)で共通処理を呼ぶ)
処理方式 例外処理・ログ出力・トランザクション制御・画面遷移などの処理方式
実装の雛形 プロジェクト・テンプレート、D 層自動生成ツール

その結果、業務開発者が書く場所はほぼ「業務コードクラスの UOC_ メソッド」に限られる。

スロットを埋める作業

Open 棟梁の B 層では、書く場所と担当者が次のように分かれている (OpenTouryo のエージェント用スキル opentouryo-layer-b の整理による)。

階層 担当 書くもの
業務コード親クラス1(BaseLogic) フレームワーク 触らない
業務コード親クラス2(MyFcBaseLogic) 纏め者(プロジェクトの基盤担当) 全業務共通の前後処理(UOC_ConnectionOpen など)
業務コードクラス 開発者 UOC_(メソッド名) に業務処理のみ
  • トランザクションの開始・コミット・ロールバック、例外時の後処理、ログ出力はフレームワークと親クラス2が行う。
  • 開発者は、決められたシグネチャのメソッドに業務処理だけを書く。

この「書く場所が決まっていて、そこを埋めればよい」状態がスロットである。

コーディング・エージェントにとっての意味

コーディング・エージェントは、解空間が広いほど「もっともらしいが、プロジェクトの方式と違う」コードを書きやすい。
開発基盤で解空間を狭めると、次の効果がある。

  • 出力のバラツキが減る:書く場所と書き方が決まっているので、正解の形が 1 つに近づく。
  • レビューしやすい:方式に沿っているかどうかを、スロットの外に書いていないかで判断できる。
  • 指示が短くて済む:方式は基盤側に入っているので、プロンプトで毎回説明しなくてよい。
  • 共通処理を壊さない:トランザクションやログはスロットの外にあり、エージェントが触る必要が無い。

人間の作業から変わっていない

この構図は新しいものではない。

  • Open 棟梁は 2007 年以来、SI 案件の治工具として、
    「開発要員によってモジュール設計や処理方式がブレない」ことを目的に使われてきた(開発基盤のKPIとKGI の「標準化の度合い」)。
  • オフショアや一括外注の現場で、スキルや文脈の異なる実装者に同じ品質で作ってもらうための仕組みでもあった。
  • 「文脈を共有していない実装者に、決められた枠の中で書いてもらう」という点で、
    コーディング・エージェントはオフショアの実装者と同じ立場にある。

つまり、人間の実装者向けに積み上げてきた標準化が、そのままエージェント向けの「ガードレール」になる。

一方、変わる点もある。標準化フレームワークは、他案件で役立て難いため、技術者に習得を敬遠されてきた。
スロットを埋める主体がエージェントになると、この習得の需給が変わる。
外部の調査を交えた整理は「標準化フレームワークの習得の需給とコーディング・エージェント」を参照。

エージェント向けの整備状況

OpenTouryo のリポジトリは、コーディング・エージェントで扱うことを前提に整備されている(2026 年 10 月時点)。

  • AGENTS.md:エージェントが守るべき方針と、参照すべき文書への入口。
  • CODING.md・CONFIGURATION.md:全領域共通のコーディング規約・設定ファイルの扱い。
  • 領域ごとの ANALYSIS.md:アーキテクチャ・ビルド手順・既知の落とし穴の一次情報。
  • エージェント用スキル(OpenTouryoCodingAgentAssets)
    • B 層・D 層・P 層(MVC / Web Forms / Windows Forms)・例外・ログ・トランザクション制御・Dao 自動生成 CLI など、
      処理方式ごとに「どこに何を書くか」をスキルとして提供している。
    • アプリ開発向けには、プロジェクトの新規構築・サンプルの変形などのスキル(新規プロジェクトのセットアップ)と、
      導入先の AGENTS.md / CLAUDE.md を生成する導入スクリプトがある。

開発基盤の処理方式が、そのままエージェントの作業手順として配布されている、ということである。

プロダクトからソリューションへ

この仕組みは、Open 棟梁というプロダクトの中に閉じたものではない。

  • 「方式を決め、書き出し、エージェントに埋めさせ、検証する」という進め方は、
    OAuth2 / OIDC アーキテクチャ、Jupyter 系の AI / BI、クラウド・デプロイなど、他の領域にも適用できる。
  • リードエンジニアが、Open 棟梁のノウハウとコーディング・エージェントを活用して、ソリューションの提供をサポートする。

これが今後の建付けである。詳しくは「ソリューション提供のサポート」を参照。

参考


Tags: 再構築

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki
開発基盤部会 Wiki

移行管理: DONE / TODO

Clone this wiki locally