Skip to content

OTR_CurrentChallenges

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

Open 棟梁の課題と対応

概要

Open 棟梁（OpenTouryo）と汎用認証サイト（MultiPurposeAuthSite）が、今直面している課題と、その対応を整理する。

  • 外部の生成 AI が挙げた課題の一覧を出発点にし、リポジトリの実態（2026-10 時点の origin/develop）に照らして書き直した。
  • 一覧では Open 棟梁と汎用認証サイトの話が混ざっていたので、どちらの課題かを分けて書く。
  • 一覧に無かった課題（担い手の集中、組織・マネジメント、AI 駆動開発の品質）を加えた。
# 課題 主に誰の課題か 対応の状況
1 .NET Framework 4.8 と .NET 10 の並行維持 両方 対で作り、両方をビルド・テストしている。net48 の終わらせ方は未定
2 セキュリティ仕様への追従 主に汎用認証サイト（部品は Open 棟梁） 03-30 / 02-10 で大きく前進。機能の実装はおおかた完了し、品質の向上の後に適合性テストの仕組みを導入する予定
3 コーディング・エージェントの時代のフレームワーク Open 棟梁 方式をエージェント向けに書き出し済み。効果の計測はこれから
4 学習コストとドキュメントの維持 Open 棟梁 覚える人を絞る。文書はリポジトリ内でエージェントと保守する
5 担い手の集中（持続性） 両方 エージェントで 1 名でも更新のペースは過去最高。知識をリポジトリに置く。レビュー・検収の担い手は課題のまま
6 組織・マネジメント 展開する組織 技術では解決しない。リードエンジニアの位置付けの問題
7 AI 駆動開発の品質（検証の設計） 両方 テストの基盤の上でエージェントに書かせ、人はレビュー方針を決める羅針盤に徹する。初回の計測では、テストがコードより厚く書かれ、回帰テストも増えている。テストの改ざんと、仕様の読み違いへの備えが要る

詳細

1. .NET Framework 4.8 と .NET 10 の並行維持

実態

  • Open 棟梁のフレームワーク本体は、主なアセンブリが *_net48.csproj と *_netcore100.csproj の対で作られている（各 10 個）。
    Web Forms・WCF（ServiceInterface/WCFService。.NET Framework 4.8 のみ）など、.NET Framework にしか無い技術の部品も残っている。
  • テストの期待値（ゴールデン・ファイル）も、net48 版・.NET 10 版・Linux 版で別に持っている。
  • 汎用認証サイトも、net48 版と net10.0 版を並行して持つ。
    両者は少しずつずれる（例：net48 版の WebAuthn は、ライブラリが対応しなくなったため 02-10（未リリース）で削除）。

対応

  • 業務ロジックとランタイム・フレームワークの間に緩衝層を置く設計で、両方を同じ方式で書けるようにしている（ランタイム・フレームワーク）。
  • ビルド・全テスト・スモークテストのスクリプトで、両方のターゲットを毎回検証する（リリース・エンジニアリング）。
  • 対の同期（片方に入れた修正を、もう片方にも入れる作業）は、コーディング・エージェントに任せやすい種類の作業で、実際にそうしている。
  • 移行の手順は バージョンアップの進め方 に纏めている。

残る課題

  • net48 版をいつ、どう終わらせるかの方針が無い。
    .NET Framework 4.8 は OS のライフサイクルに従ってサポートされるので、利用者の既存資産がある限り続く。
  • 片方にしか無い機能が増えると、「同じ方式で書ける」という前提が崩れていく。差を一覧で管理する必要がある。

2. セキュリティ仕様への追従

実態

主に汎用認証サイトの課題で、Open 棟梁はその部品（JWT・JWS・JWE・SAML2・OAuth2 / OIDC のクライアントなど）を提供する立場にある。

領域 状況（origin/develop）
FAPI（Part 1・2）、CIBA、mTLS 以前の版から実装がある。mTLS のトークンの紐付けは、02-10 で RFC 8705 の形式に直した
PAR・DPoP・DCR・ログアウト 02-10 で追加（汎用認証サイトの ANALYSIS-IdP.md の D 項目は、D-14 を除いて対応済み）
OAuth 2.1 への整合 02-10 で既定を変えた（雛形の Implicit / ROPC を無効、PKCE の扱い）
XML 署名の付け替え（XSW） Open 棟梁の SignedXml2.Verify が署名の数学的な正しさしか見ていなかったのを、2026-10-19 に直した（署名の対象と、消費する要素の一致を確認）
署名・暗号の既定 Open 棟梁 03-30 で、SAML2 の署名の既定を SHA1 → SHA256、ECB を非推奨、パスワードからの鍵の導出を修正など

対応

  • 仕様との差を、エージェントに適合性の分析（ANALYSIS-IdP.md）として洗い出させ、項目ごとに Issue にして直す、という進め方を取っている。
  • 直した振る舞いは、E2E テスト（3 方言の DB）で回帰を検知する。
  • 汎用的な部品は、汎用認証サイトから Open 棟梁へ移している（OTR #634）。

残る課題

  • 適合性テストの仕組みが、まだ無い（D-14。OpenID Foundation の Conformance Suite を回す仕組み）。
    自前のテストでは、仕様の読み違いをそのまま正しいと判定してしまう。
    汎用認証サイトの機能の実装はおおかた完了しているので、品質の向上（7）の後に、D-14 を導入する予定である。
  • 修正の多くは後方互換性に影響する（sub の値、redirect_uri の比較、署名の既定、暗号文など）。
    利用者の移行の手間が増えるので、リリース情報で後方互換性を明示し続ける必要がある。
  • 仕様は今後も変わる。追従を続けられるかは、5 の担い手の問題でもある。
  • セキュリティの取り込みの品質を、エージェントのレビューとテストでどこまで上げられるかは、7 を参照。

3. コーディング・エージェントの時代のフレームワーク

実態

対応

  • 方式を、エージェントが読める形で書き出している。
    • リポジトリの AGENTS.md・CODING.md・領域ごとの ANALYSIS.md（19 個）。
    • エージェント用スキル（OpenTouryoCodingAgentAssets）。常に載せるインストラクションと、必要なときだけ読まれるスキルに分けている。
  • 開発者（エージェント）が触る固有の API を、UOC_ メソッドなどのスロットに絞っている（コーディング・エージェント時代の開発基盤）。

残る課題

  • 効果は、Open 棟梁を使った案件ではまだ計測していない（開発基盤のKPIとKGI）。
    フレームワーク自体の開発では、更新のペースが大きく上がった（5 を参照）。
  • スキルは、フレームワークの版が上がるたびに古くなる。版の差分（詳細なリリース情報）からスキルを直す流れを作る必要がある。

4. 学習コストとドキュメントの維持

実態

  • 厳格な層構造・共通処理・設定ファイル・独自の実装パターンがあり、参画する開発者にとって学習コストが高い。
  • 加えて、標準化フレームワークは他の案件で出会う確率が低いので、技術者に習得を敬遠されてきた（需給の問題）。

対応

  • 覚える人を絞る：方式を決めて検証するリードエンジニア・纏め者が深く理解し、スロットを埋める作業はエージェントに任せる
    （標準化フレームワークの習得の需給とコーディング・エージェント）。
  • 文書をリポジトリの中に置き、エージェントと一緒に保守する：ANALYSIS.md・TESTING.md・CONFIGURATION.md など（汎用認証サイトの作業中ブランチでは、設計の経緯を DesignNotes/ に分けている）。
    コードの変更と同じ PR で文書も直すので、ずれにくい。
  • 利用者向けの情報は、この Wiki（使い方・リリース）と、GitHub の Wiki（チュートリアル）に分けている。

残る課題

  • AI に任せるほど、人の理解は落ちる、という調査がある。検証できる人を育てる仕組みが別に要る。
  • GitHub の Wiki（チュートリアル）と、リポジトリ内の文書・この Wiki の間で、内容がずれうる。

5. 担い手の集中（持続性）

外部の生成 AI の一覧では「コミュニティでの貢献とフィードバックの循環」として触れられていたが、実態はより具体的である。

実態

  • 03-20 以降の Open 棟梁の develop のコミット（マージを除いて 277）は、依存パッケージの自動更新（3）を除き、1 名のアカウントによる。
    汎用認証サイトの 02-00 以降（312）も同じである。
  • 一方で、更新のペースは大きく上がっている。コーディング・エージェントを使い始めた影響である。
年 Open 棟梁 汎用認証サイト 備考
2017〜2019（ピーク） 190〜287 / 年 100〜132 / 年 活発に開発していた時期（当時も主な担い手は同じ）
2020〜2022 13〜60 / 年 5〜28 / 年 保守中心
2025 46 1 03-10・03-20 のリリース
2026（〜10 月） 276 311 ほぼ 7〜10 月の 4 か月分

（origin/develop のマージを除くコミット数。2026-10 時点）

  • 2026 年は、4 か月ほどで、過去の最も多かった年の 1 年分に並ぶか超えている
    （Open 棟梁は 2026-08 の 1 か月で 182、汎用認証サイトは 2026-09〜10 の 2 か月で 308）。
  • しかも、件数だけでなく中身も重い。差分の本体を読むと、セキュリティの修正・テストの拡充・設計文書の整備が大半を占める
    （詳細なリリース情報の未リリース区間。汎用認証サイトは約 27 万行の追加）。
  • つまり、コーディング・エージェントで同じ 1 名が、活発だった頃の数倍の速さで書けるようになった。

対応

  • 知識を、人ではなくリポジトリに置く（AGENTS.md・ANALYSIS.md・スキル・詳細なリリース情報）。
    担い手が替わっても、エージェントと一緒に引き継げるようにする。
  • リリースの手順を、スクリプトとエージェントの作業に落としている（リリース・エンジニアリング）。

残る課題

  • レビュー・検収の担い手。書く手はエージェントで増やせるが、検証する人は増やせない。
    ペースが上がった分だけ、検証が追い付かなくなる。
    develop → master の PR はレビュー 1 名が必須なので、ここが詰まるとリリースが止まる。
    人が個々の変更を見るのではなく、レビューの方針を決める役に回る、という対応は 7 を参照。
  • 利用者からのフィードバック（Issue・事例）を集める経路が細い。

6. 組織・マネジメント

外部の生成 AI の一覧には無かったが、開発基盤の横展開を妨げてきたのは、技術よりもこちらである。

  • 課題の多くは、ポートフォリオ・プログラム・マネジメントと、ステークホルダー・エンゲージメントの問題である
    （開発基盤を横展開する際の課題）。
  • コーディング・エージェントで、方式は対面の信頼関係が無くても浸透するようになった。
    残るのは、方式を決め、書き出し、検証するリードエンジニアを、組織がどう位置付けるかである（ソリューション提供のサポート）。

7. AI 駆動開発の品質（検証の設計）

AI 駆動開発で、品質をどこまで上げられるか。
見立ては、TDD ベースの要件駆動・仕様駆動、テスト自動化、コーディング・エージェントのレビュー能力で、かなり有効というものである。

見立て（進め方）

  • テストのインフラを先に構築し、その上でコーディング・エージェントに徹底的にコーディングしてもらう。
  • 人はレビュー役に徹する。もっと言えば、個々の変更を具体的にレビューするより、
    レビューの方針を決める羅針盤の役割を担う。

外部の知見（有効と言える根拠）

観点 知見
テストを先に渡す 問題文に人が書いたテストを添えると、LLM が正しく解ける問題が増える（GPT-4 で、MBPP は +12.0%、HumanEval は +8.5%）
AI によるレビュー 産業の事例で、AI のレビュー・コメントの 73.8% が「解決済み」になった。ただし品質の向上は「小さい」と受け止められ、PR を閉じるまでの時間は延びた（5 時間 52 分 → 8 時間 20 分）。的外れな指摘もある
脆弱性の発見 Google の Big Sleep は、FFmpeg・ImageMagick などで 20 件の脆弱性を見つけた（開示前に人が確認）。一方、ノイズは多い（o3 で Linux カーネルのゼロデイを見つけた事例では、本物と誤検知の比が約 1:50）
組織の土台 DORA 2025 は、AI を「増幅器」と位置付ける。強い組織の長所も、弱い組織の短所も増幅する。テストの基盤があることが前提になる

外部の知見（羅針盤が要る理由）

落とし穴 知見
生成したコードは安全とは限らない Veracode の調査では、セキュリティが関わる課題の 45% で、AI が安全でない書き方を選んだ（XSS の対策の失敗は 86%）。モデルが新しくなっても改善していない
テストのごまかし ImpossibleBench では、仕様どおりでは通らないテストを、エージェントがテストの書き換えなどで通した（GPT-5 は、ある課題群の 76%）
同じ読み違いの共有 同じエージェントが書いたテストとコードは、仕様の読み違いを共有する。自前のテストでは見つからない（2 の D-14）

対応（羅針盤として決めること）

  1. 何を正とするか：仕様の出典、受け入れ基準、外部の適合性テスト。
  2. テストを守る：エージェントによるテストの変更は、差分を人が必ず見る。変えてよい条件を決めておく。
  3. レビューの観点を書き出す：セキュリティの観点（CWE、署名の検証、リプレイ対策など）を AGENTS.md・スキルに書く。
  4. 作る役と検証する役を分ける：別のエージェント・モデル、CodeQL のような別系統の検査を使う。
  5. 見つかった問題を、回帰テストとレビューの観点に変える：同じ型の問題を再発させない。羅針盤の中身が育っていく。

計測（初回。2026-10 時点の origin/develop）

開発基盤のKPIとKGIの「AI 駆動開発の品質の指標」で、リポジトリから取れる数値を集めた。

指標 Open 棟梁 汎用認証サイト
テストの件数 NUnit のテストの属性：03-20 の 0 → 943（2026-10-15 に NUnit のテストを導入。#610）。従来からの Golden のテストに加えて E2E のテストケース：02-00 の 0 → 384（2026-09-08 に導入）
カバレッジ（NUnit、net10.0） Public：80.0% → 80.6%（10-19 → 10-22）。Framework の対象モジュール：83.6%（14 モジュール）→ 94.6%（38 モジュール）。Dam：約 89% （集計の仕組みは無い）
テストとコードの追加行数 2026-08：テスト +16,783 / ライブラリ +2,886。2026-10：テスト +20,501（ゴールデン・ファイルの新設 8,097 を含む） / ライブラリ +12,288 2026-09：テスト +30,599 / コード +12,967。2026-10：テスト +34,526 / コード +33,612
期待値の変更 2026-10 に、ゴールデン・ファイル（Result*.txt）を変えたコミットが 8 件（うち 1 件は新設）。すべてコードの変更と同じコミットで、期待値だけを変えたコミットは無い —
回帰テストの数 — Issue に紐付いた回帰テスト（RT-<Issue>）：58 件の Issue・指摘に対して 263 ケース
仕様の根拠の付与 — テストケース一覧の各ケースに、根拠（RFC・OIDC の該当箇所）を書く形式。JWT のデコードと署名の検証は、実装側のコードを使わず独立に行う
手戻り 2026-07 以降の 273 コミットのうち、「漏れ」の追加の修正が 14（約 5%）。閉じた Issue は 86 308 コミットのうち 9（約 3%）。閉じた Issue は 111
静的解析の指摘 CodeQL の指摘への対応のコミットがある（2026-08、2026-10。例：テストの RSA 鍵長、code-scanning/53）。指摘の件数は GitHub 側にあり、数えていない —

読み取れること

  • テストの基盤の上で書く、は実際に起きている。どの月も、テストの追加行数がライブラリ・コードの追加行数を上回っている （Open 棟梁の 2026-08 は約 5.8 倍、汎用認証サイトの 2026-09 は約 2.4 倍）。
  • 見つかった問題を回帰テストに変える、も起きている。汎用認証サイトでは、Issue ごとの回帰テストがテストケースの約 7 割を占める。
  • 同じ読み違いの共有への備えも、一部は入っている。汎用認証サイトの E2E は、期待値に仕様の根拠を書き、JWT を実装と独立に検証する。 ただし、根拠の読み方そのものが誤っていれば見逃すので、外部の適合性テスト（D-14）で補う。
  • 期待値の変更は、コードの変更と一緒に起きている。これはテストの改ざんの典型（期待値だけを書き換える）ではないが、 どちらが正しいかは差分を読まないと分からない。ここが、人が羅針盤として見るべき箇所である。

計測の限界

  • 行数・コミット数は、生成物・サンプル・文書を含み、粒度も一定でない。推移を見るための数値である。
  • 「漏れ」はコミット・メッセージからの数え方で、手戻りのすべてではない。
  • 利用者の環境での不具合（品質の流出）は、まだ測れていない。

事例：SAML の問題の抽出

  • Open 棟梁の SignedXml2.Verify が、署名の数学的な正しさしか見ておらず、署名の付け替え（XSW）が通りえたのを、2026-10-19 に直した（2 の表）。
    同じ日に、単体テストの追加・カバレッジの自動集計・CodeQL の指摘への対応が入っており、テストの基盤を固める作業の中で見つかっている。
  • コミットには「相互に鍵を交換している SAML2 でのリスクは低くはある」と添えられている。リスクの評価は人が行っている。
  • こうした取り込みで、セキュリティ周辺の問題は減ると期待できる。ただし、効き方は問題の種類で違う。
    • 減らせる：XSW のような、名前の付いた既知の攻撃の型。LLM がよく知っており、観点として書き出せる。
    • 残る：仕様の読み違いや、組み合わせで生じる問題。適合性テストと人の判断が要る。

残る課題

  • テストの改ざんを、仕組み（テストの変更の差分レビュー、テスト・ファイルの保護など）で防ぐ必要がある。
  • 計測は初回を行った段階で、基準値と推移はこれから（開発基盤のKPIとKGI）。
    期待値の変更の差分レビューを、記録に残る形にする必要がある。品質の流出（利用者の環境での不具合）は、まだ測れていない。
  • 外部の適合性テスト（2 の D-14）を導入するまでは、仕様の読み違いは、エージェントのレビューでも見逃しうる。
    品質の向上の後に導入する予定で、そこで初めて、外部の基準で品質を確かめられる。

参考

Tags: 再構築

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

NetDevInfraWiki

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

移行管理: DONE ／ TODO

Clone this wiki locally