Skip to content

OTR_CoreAndBranches

Jump to bottom
nishi_74322014 edited this page Oct 30, 2026 · 4 revisions

コアと枝葉

概要

「Open 棟梁の強みはコアを持っている点にある」という主張を、リポジトリの実態と外部の知見で検証する。

  • 主張の要旨
    • コア（Open 棟梁）は SoR 寄りではあるが、コアがある分、枝葉を広げていくことは容易である。
      これは、コーディング・エージェントで加速していく。
    • 一人のエンジニアで出来ること（やらなくてはならないこと）は、爆発的に増えている。
      テスト自動化、コンテナ化、Frontend、WebAPI、IdP / STS、クラウド、IoT、データ・パイプライン、AI / BI。
    • SoE・SoI の領域は、基盤が不安定（設計変更、脆弱性報告の多発）で、コスパの観点からペイラインに乗ってこなかった。
      コーディング・エージェントで、この前提が大きく覆された。
    • したがって、ここ数年は SoE・SoI に枝葉を伸ばしていくフェーズにある。
    • 検証の不安はあるが、コアがある分、他は使い捨てが効く。これは、基盤が不安定な SoE・SoI での処世術の可能性がある。
    • 最新のベストプラクティスも、コーディング・エージェントに委任できる。
  • 検証の結果（要約）
    • コアと枝葉の構造、枝葉の広がり、枝葉の入れ替わりは、リポジトリの上で確認できる。
    • 「安定したコア＋使い捨ての周辺」という考え方は、ペース・レイヤー（Gartner）や、生成 AI 時代の「使い捨てのソフトウェア」の議論と一致する。
    • ただし、使い捨てが効くのは枝葉の実装に限られる。境界の契約（API・トークン・データ）と、セキュリティは捨てられない。
    • ベストプラクティスの委任は、最新の文書を渡し、人が検証することが条件になる。エージェントが覚えている知識は古いことがある。

詳細

検証1：コアと枝葉は、リポジトリの上でも分かれているか

OpenTouryoProject と NetDevInfraWGinOSSConsortium のリポジトリを、主張に挙がった領域に当てはめた（2026-10 時点）。

区分 領域 リポジトリ 最終更新 コアとの関係
コア 業務システム（SoR） OpenTouryo 2026-10 —
枝葉（リファレンス実装） IdP / STS MultiPurposeAuthSite 2026-10 Open 棟梁の部品（JWT・SAML2・OAuth2 / OIDC）の上に作る。汎用的な部品は Open 棟梁へ戻している（後述の「コアと枝葉の境界は動く」）
枝葉 テスト自動化 OpenTouryo・MultiPurposeAuthSite の中のスクリプト 2026-10 全テスト・E2E・スモークテスト（リリース・エンジニアリング）
枝葉 WebAPI ResourceServerTemplates 2026-10 ビルドのスクリプトが OpenTouryo のソースを取得し、net48 版・.NET 10 版のアセンブリを作って取り込む
枝葉 Frontend FrontendTemplates（SPA・Hybrid・Native・XPlat） 2026-06 サンプルが Open 棟梁の WebAPI・汎用認証サイトを呼ぶ
枝葉 コンテナ化 LocalServicesOnDocker・ASPNETMVCOnDocker 2026-10・2026-07 ローカルの RDB・NoSQL、ASP.NET Core MVC の Docker 化
枝葉 クラウド・IoT・AI / BI DxCommon（AzureIaC・Edge・Notebook・Agent） 2026-03 Edge のクライアント（Mosquitto・RabbitMQ）が Open 棟梁の設定の部品を使う
枝葉 IoT・データ・パイプライン HubAndMsgSrv・DataPipeline 2023-09・2022-12 —
枝葉 Docker 上の構成 OAuth2OidcArchitOnDocker・ServicePlatformOnDocker・MVCSampleOnDocker 2021 Keycloak・Kong などの評価
エージェント 方式の書き出し・検証 OpenTouryoCodingAgentAssets・VerifyCaSkillsForOT・NorthwindDbSampleSpec・CodingAgentPlayground 2026-07〜09 コアの方式を、エージェントが読める形にする

読み取れること

  • 枝葉は、コアを取り込む形で作られている。
    WebAPI のテンプレートはコアのソースからアセンブリを作り、IoT のクライアントはコアの部品を使い、Frontend のサンプルはコアの WebAPI を呼ぶ。
  • 一人で扱う範囲は広い。上の領域は、ほぼ同じ担い手が扱っている（Open 棟梁の課題と対応の 5）。
  • 枝葉は入れ替わり、コアは続いている。
    • 2021〜2023 年の Docker 上の構成・IoT・データ・パイプラインのリポジトリは、更新が止まっている。
      FrontendTemplates にも、置き換えられた old フォルダ（React、XPlat）がある。
    • 一方、コアは 2007 年から続き、2026 年には過去のピークの年に並ぶほど更新されている。
    • 枝葉の使い捨ては、方針として決める前から、実態として既に起きていたことになる。

検証2：SoE・SoI の基盤は不安定か

  • GitHub の 2025 年のレビューでは、新たに報告された脆弱性が前年比 19% 増え、npm のマルウェアの勧告は 69% 増えた（Shai-Hulud などのキャンペーン）。
    脆弱性の型で最も多いのは、今もクロスサイト・スクリプティング（CWE-79）である。
  • JavaScript の MV* フレームワーク、モバイル、npm の文化圏は、世代交代が速い（開発基盤のKPIとKGIの「バージョンアップの指標」）。
  • 認証の領域も、仕様の追加・改訂が続いている（OAuth 2.1、FAPI、DPoP など。Open 棟梁の課題と対応の 2）。

主張のとおり、SoE・SoI の基盤は、設計変更・脆弱性報告の両面で不安定と言える。

検証3：エージェントで、コスパの前提は覆ったか

覆りつつある、という材料

  • 自分たちの開発：同じ担い手で、2026 年の数か月のコミット数が、過去のピークの年の 1 年分に並ぶか超えた（Open 棟梁の課題と対応の 5）。
  • 外部の事例：Brex は、自前のエージェントで、1 名のエンジニアが 1 か月で 180 のマイクロサービスのフレームワークを移行したと報告している（自社の報告で、監査されていない）。
    なお、1 つの大きなエージェントで行った最初の試みは、コンテキストの過負荷と幻覚で失敗している。
  • 研究：J.P. Morgan AI Research の、依存ライブラリの更新を行うマルチエージェントの研究は、「適合率 71.4%」を報告している。
    ただし、これは合成した 3 つのリポジトリのうち 1 つのシナリオで、エージェントが削除した 7 行のうち 5 行が、人の作った正解のパッチと一致した、という小さな数値である。
    また、テストが網羅的でないことを、著者自身が断っている。
    追随の手間は減らせるが、全自動にはならず、検証が要る、という程度に受け取るのが妥当である。

追随の主な手段は、パッチではなくリプレース

  • 実務では、脆弱性にパッチ・レベルで対応する（ライブラリのコードを自分で直す）ことは、ほとんどしない。
    脆弱性への対応が芳しくないライブラリは、リプレースするのが基本である。
  • 自分たちのリポジトリでも、そうしている。
    • Open 棟梁：JWT の ECC 鍵の変換で jose-jwt をやめ、.NET 標準の ECParameters に置き換えた（#374、2026-08。詳細なリリース情報（03-00〜））。
    • 汎用認証サイト：net48 版の WebAuthn は、ライブラリ（Fido2）が .NET Framework に対応しなくなったため、02-10（未リリース）で削除した。
  • リプレースは、エージェントが有効に働く種類の作業である。
    • Python の実際のライブラリ移行 321 件（PyMigBench）で、GPT-4o は個々のコード変更の 94% を正しく移行し、
      移行の 57% を完全に正しく行った（開発者の移行との比較）。テストで見ると、64% が開発者の移行と同じテストを通った。
    • これを元にした仕組み（MigrateLib）は、別の 717 件で、32% を人の手を入れずに完全に正しく移行した。
    • つまり、大部分の変更はエージェントに任せられ、移行の単位で見ると人の仕上げと検証が要る。
      コアとの境界の契約がテストされていれば、仕上げと検証の範囲を絞れる。
  • リプレースできることは、「使い捨てが効く」ことの一部でもある。
    枝葉が特定のライブラリに縛られていなければ、ライブラリごと捨てて入れ替えられる。

「安定したコア＋変化の速い周辺」という考え方の裏付け

  • Gartner のペース・レイヤー型アプリケーション戦略（2012）は、アプリケーションを SoR（記録）・差別化・イノベーションの 3 層に分け、
    層ごとに、変化の速さ・統治・調達・投資の仕方を変えるべきだとしている。
    • Thoughtworks の Technology Radar（2015）は、変更は複数の層をまたぐことが多いとして、これを「Hold」にした。
      ただし、「部品ごとに変化の速さが違う」という核心は妥当だとしている。
    • Open 棟梁では、コアと枝葉の間に緩衝層を置いて、層をまたぐ変更の影響を抑える（ランタイム・フレームワーク）。
  • 生成 AI の時代の「使い捨てのソフトウェア」の議論では、
    「人が書く耐久性のあるコア＋変えない API の契約＋AI が生成する使い捨ての部品」の 3 層が提案されている。
    ただし、この議論の多くはブログで、本番のソフトウェアが作り直しで回っているという証拠は薄い。

検証4：最新のベストプラクティスは、エージェントに委任できるか

条件付きで委任できる。

  • エージェント（LLM）は、学習データの時点で知識が止まっているので、非推奨の API や古い書き方を、もっともらしく書く。
    バージョンを指定したコード生成（VersiCode）は、強いモデルでも難しいという研究がある。
  • 対策として、最新の公式文書をエージェントに渡す仕組み（Context7 などの MCP サーバー）、ルール・ファイル、CI での lint が使われている（効果の数値は、提供元の主張にとどまる）。
  • 学習データに少ない固有の API が苦手で、文書を渡すだけでは足りない、という研究もある
    （標準化フレームワークの習得の需給とコーディング・エージェント）。

したがって、委任できるのは「最新の文書を調べて、当てはめる」作業である。
どのベストプラクティスを採るかの判断と、当てはめた結果の検証は、リードエンジニアに残る。

使い捨てが効く範囲

捨ててよいもの（枝葉の実装） 捨てられないもの
UI・画面、サンプル、PoC コアの方式（層・処理方式・例外・トランザクション）
Notebook、分析のスクリプト 境界の契約：WebAPI の I/F、トークン・クレーム、データの形式
コンテナ・IaC の設定 認証・認可、暗号、署名の検証（セキュリティ）
特定のライブラリへの追随のコード 利用者に渡したもの（後方互換性。リリース）
  • 検証の重さを、コアと枝葉で変える。
    • コアは重く検証する（全テスト、3 方言の DB の E2E、ゴールデン・ファイル）。
    • 枝葉は、コアとの境界の契約だけを確かめ、壊れたら直すより作り直す。
  • これが、「検証面の不安」に対する答えになる。枝葉を捨てられるのは、コアと契約が検証されているからである。

コアと枝葉の境界は動く（汎用認証サイトの例）

どこまでがコアで、どこからが使い捨てかは、固定ではない。汎用認証サイトがその例である。

  • 汎用認証サイトは、今はリファレンス実装である。
    3.0 で、品質保証されたプロダクトとしてのリリースを目指している（まだ目標である。経緯は下記）。
    IdP / STS には、Keycloak などの既存のプロダクトという選択肢もある。
  • 一方、クライアント側の部品は Open 棟梁（コア）に入れる意味がある。
    Open 棟梁の Framework/Authentication には、OAuth2 / OIDC のクライアント（認可要求、グラント、トークン管理、DPoP、動的クライアント登録）、
    JWT・JWK Set、SAML2 のバインディングがあり、汎用認証サイトで育てた汎用的な部品も移している（OTR #634）。
  • これが成り立つのは、IdP と業務システムの間の**境界の契約が、標準の仕様（OAuth2 / OIDC・SAML2）**だからである。
    契約が標準なら、IdP 側は自前の実装でも Keycloak でも差し替えられ、クライアント側はコアに置いて使い続けられる。
  • つまり、汎用認証サイトは「IdP として使われ続けるなら枝葉の中でもコアに近い」が、
    「Keycloak に置き換えるなら、仕様を検証するためのリファレンス実装として使い捨てられる」という揺らぎを持っている。
    どちらに転んでも、仕様の理解とクライアントの部品はコアに残る。
  • 汎用認証サイトそのものがコアに加わる可能性もある。
    それを決めるのは、現時点では、コーディング・エージェントでどこまで品質を上げられるかである。
    • IdP は、仕様が広く、変化が速く、セキュリティの要求が厳しい。1 名の担い手で、プロダクトとして使える品質を保てるかが問われる。
    • 2026 年は、エージェントに仕様との差を洗い出させ（ANALYSIS-IdP.md）、項目ごとに直す進め方で、短期間に多くの差を埋めた
      （D 項目は D-14 を除いて対応済み。Open 棟梁の課題と対応の 2）。
    • 一方、適合性テスト（D-14）は残っていて、エージェントと自前のテストだけでは、仕様の読み違いを見逃しうる。
      機能の実装はおおかた完了しているので、品質の向上の後に、D-14 を導入する予定である。
      外部の適合性テストを通せるか、利用者の案件で使えるかが、コアに加える判断の材料になる。

この揺らぎは弱みではなく、攻めの姿勢の表れである。

  • 枝葉を自分で作ってみることで、仕様を深く理解し、その成果をコアに取り込む。
  • 枝葉そのものを使い続けるか、既存のプロダクトに譲るかは、後で決めればよい。
  • エージェントで作るコストが下がったので、「作ってみて、残すものと捨てるものを後で選ぶ」進め方が割に合うようになった。

汎用認証サイトの経緯（品質保証が律速だった）

汎用認証サイトがリファレンス実装に留まってきた理由は、機能ではなく品質保証である。

  • はじめは ASP.NET Identity で実装を始めた。仕様が狭い（OAuth2）うちは、認証基盤として案件で使った実績もある。
  • OIDC、さらに様々な拡張、SAML などに対応して以降は（この辺りから、STS の部分は ASP.NET Identity のガードレールを外した）、
    リファレンス実装に留まっていた。実装が複雑になるにつれて、品質保証に手が回らなくなったためである。
  • 最近はリファレンス実装の実装も滞っていたが、コーディング・エージェントの登場で変わりつつある
    （年ごとのコミット数は Open 棟梁の課題と対応の 5）。
  • 2.0 系は始まったばかりで、3.0 で、品質保証されたプロダクトとしてのリリースを目指す。
  • それまではリファレンス実装なので、本番利用は想定しない。修正は行うが、アドバイザリーの発行は約束しない。
    リポジトリの Security.ja.md も、リファレンス実装でありテンプレートであるとし、派生させた環境の堅牢化は構築者の責任としている。

まとめ（処世術として）

  • 不安定な基盤（SoE・SoI）の上では、すべてを保守し続けるより、
    安定したコアを持ち、枝葉はエージェントで作り、合わなくなったら作り直すほうが割に合う。
  • コアを持つことは、SoR の資産であると同時に、SoE・SoI に枝葉を伸ばすための足場になる。
  • 枝葉で得たもののうち、汎用的なもの（標準の仕様のクライアントなど）はコアに取り込み、残りは使い続けるか捨てるかを後で選ぶ。
  • まだ検証していないこと
    • 枝葉を作り直すコストの実測（作り直しと保守の比較）。
    • 利用者の案件（自分たちのリポジトリの外）で、同じやり方が回るか。

参考

Tags: 再構築

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

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

移行管理: DONE ／ TODO

Clone this wiki locally