Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール？〜

Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール？〜 AIの出力の質を上げる！チームの集合知を注入する方法
2025年6月25日株式会社ログラス 1

# メインの問いどこにどう注入するか？どこから抽出し、どう整理するか？開発プロセスにおいて、 AIの出力の質を上げるために、チームの集合知を注入する方法

どこにどう注入するか？ 3

# どこにどう注入するか？ - 主張コード(型・関数・テスト)が第一級コンテキストで、細かい規約はリントで守る、残った手順的知識やサマリ・インデックス的知識は自然言語のruleに落とす決定的非決定的 PR作成手順ビルド・テスト手順
手順的知識ドメイン語彙/ユースケースそのコードベースの知識ドメイン知識関数型スタイルレイヤ分離やテストのお作法規約的知識写すそのまま書くキャッシュする/ インデックスする制約を実装語る

# どこにどう注入するか？ - 理由非決定性を最小化し、２重メンテを避けつつ概念・考え方をAIと共有するため非決定性の最小化決定的に実装できるルールは決定的に自然言語より解釈揺れが無い知識の単一情報源化自然言語との２重メンテ回避
コードとドキュメントの距離がゼロ (というか一致) 最も具体的な指示(例示) 自然言語での指示は追随性が低い実際のコードで語った方が思惑に沿ってくれる型付き概念部品の提供レゴブロックとしての概念を別ユースケースでも使用具体的な「機能」だけでなく「業務概念」とその理解をAIと共有

# どこにどう注入するか？ - 組織文脈ストック的な文書をメンテしていく文化、仕様・規約を日本語でメンテする文化は薄い「その場の知っているかどうかの知識」をAI Readableにしておくことは必須「やった自分はわかる」状態を作る、暗黙知負債の負債度合いが急上昇新規事業・新機能開発のビジネス要求が強い中、既存知識の明文化はそこまで進められていない…

# どこにどう注入するか？ - 組織文脈それでも…俺たちにはDDDがあるよ！ https://speakerdeck.com/loglass2019/loglass-in-10-min-for-engineers?slide=44 エンジニア向けカンパニーデックより @kawashima さんによる書評
https://qiita.com/kawasima/it ems/05f231653ef773697991# architecture-modernization https://www.manning.com/books/architecture-modernization https://matarillo.com/dmmf/

# どこにどう注入するか？ - 一周回ってDDD Code as 業務知識の引継書 (対AI・人間) Code as
合わせて欲しいスタイル・お作法 Code as Context 業務フロー・その目的 -> 関数を合成した関数・その名前業務手順・その目的 -> 関数・関数名ビジネスルール -> 関数業務データ・イベント -> データ・イベントの型業務データの構造・サブセット関係 -> ADT 状態遷移とその制約 -> 関数のシグネチャ業務概念とその階層 -> モジュール実例を明示 Code as ドメイン知識 Code as スタイルガイド渡す追加コンテキストが最小限自然言語より解釈揺れが無い実例に追従したコードを書かせ易い開発時は自己参照

# どこにどう注入するか？ - 自然言語・ruleで補完する部分全てを完全にコードに意図込めできる訳ではない性能等のため -> コメント業務上の背景 ->
コメントなぜそう書いているか？より上段/全体の背景/目的一般的に従って欲しい心構え典型的にはその機能全体の概要・目的などコード全て舐めれば把握可能かもしれないが、非効率 → .md として書く。ある意味キャッシュ蒸留されたサマリキャッシュとしての概要主要概念へのインデックス基本、抽象度の高いお気持ち指示は通りが悪い → rule として書くが、実例となるコード (sample)やtemplate をリンク

# どこにどう注入するか？ - as Context としてのコードとスピードの両立には？スピードと両立するには？品質ブレがあるのでは？人間に書かせないでAI様に書いていただくドメイン知識の
Single Source of Truth としてのコード（ここだけ永続化）３重メンテせず、都度ビューとして復元自然言語コードのマッピング Rule それぞれ半構造化された空テンプレ/ サンプルは必要

# Appendix – コードでの知識表現仕訳集約は登録された/訂正された/承認されたのイベントを返す（コマンドも同様）登録コマンドには、
- 明細二行以上 - 貸借の一致のビジネスルール仕訳集約は登録された/訂正された/承認されたのイベントを返す（コマンドも同様）登録コマンドには、 - 明細二行以上 - 貸借の一致のビジネスルール

# どこにどう注入するか？ - Appendix (参考)サンプルコード/サンプルルールも含めた、より具体にフォーカスした話 https://speakerdeck.com/yodakeisuke/agent-rules-as-domain-parser- 10303fa7-cf85-4df5-a1fa-6f511f88d5a7

# どこにどう注入するか？ - 可読性に関する私見対人間と同じように、コードに自然言語的な意味を持たせることは今後も必要か？（もはや機械語のように扱えば良いのではないか？） LLMがLLMである限り（自然言語で情報を受け取り、自然言語で考えているように見える）コードに自然言語的な意図込めをすることに意味はあるのではなかろーかコードに、①単なる実行命令だけではなく
②自然言語的な意味ベクトルのニュアンスも付与し、コンテキストとなすというかそもそも、現状Agentは自然言語の単語でgrepしてコードベース理解している

# どこにどう注入するか？ - 結論どこにどう注入するか？ → コードに知識を写す形で注入する

どこから抽出しどう整理するか？ 15

# どこからどう抽出・整理するか？ - スコープドメイン知識の抽出整理が最もコモディティ化せず、扱う量も多い大量/ 独自性高 PR作成手順ビルド・テスト手順手順的知識
ドメイン語彙/ユースケースそのコードベースの知識ドメイン知識関数型スタイルレイヤ分離やテストのお作法規約的知識少量/ 独自性低独自ルールを書かずともツールや LLM自体がカバーするようになっていっている独自性が高く、知識としての絶対量も多いため、ドメイン知識をフォーカスして扱う

# どこからどう抽出・整理するか？ - どこから？知識のソース知識の獲得元はなんといっても real world

# どこにどう注入するか？ - AI駆動開発の２大ネックしかしreal worldから、どうやって知識を抽出し整理する？要件からコード生成できるようになる、などというが… 「要件」「仕様」をいい感じに抽出・合意・整理するこれだ！というプラクティス・フォーマットは有史以来存在していない問題とも共通の課題
（UMLやRDRA、sudoモデリングなどの提案はある/あったものの…）加えて、人間のレビュー・QAもネック化

# どこにどう注入するか？ - BDDという仮説それでも…俺たちにはBDDもあるよ！（形式手法もあるよ） BDD、形式手法、型の3段階でAIにガードレールを与えるというAI駆動開発のひとつの型を実践して提案 @nakamura_meg @itohiro73 @urmot2

# Appendix BDD概要時代の要請に一定の回答を与える「要件・仕様」を関係者で決める、形式的に表現するところがネックになっていっている「こうあるべき」の宣言(２値の評価関数)からシステムを生成することになっていっている

# Appendix BDD概要 Example Mapping 形式的なユーザシナリオ「仕様」をブレストするコラボレーションツールのようなもの ATDD、TDDに接続しやすいユーザシナリオ記述

# どこからどう抽出・整理するか？ - 主張 BDDで評価基準・具体例・振る舞いを見出し、DDDで評価対象・概念・領域を見出す具体例を収集こうなったとき・どうなればいいのかの発見・定義具体領域を引いて、
あるべき状態を定義し、収束させていく具体例を収集こうなったとき・どうなればいいのかの発見・定義振る舞い・検証抽象化・一般化業務概念の発見・定義概念間の関係・全体観を表現概念粒度に応じた領域・境界の定義 - 境界づけられたコンテキスト - 集約 - モデル、バリュー領域・境界 BDD: 評価基準 DDD: 評価対象 https://x.com/t_wada/status/1922110843270885789

# Appendix DDD概要領域を引き、概念の境界を与える - 境界づけられたコンテキスト - 集約 - 型付きドメイン語彙
全体観や、概念同士の関係を表現 - 動的関係（フロー） - 静的関係（構造）

# Appendix BDDと形式手法の比較・併用・ BDDは『みんなで共通理解を作る』・形式手法は『数学的に証明する』「こういうときはどうなる？」仕様の発見という用途は同じ

# どこからどう抽出・整理するか？ - 開発プロセスにおいて W字モデルの如く、BDDラインとDDDラインで攻める

# どこからどう抽出・整理するか？ - 両者を掛け合わせる必要性テストだけ人間が見る場合でも、テスト数や因子水準が爆発し管理不能になることを避けるこちらからのみアプローチする（具体・機能のみ見る）と… 因子水準が爆発するテストの分割、階層管理が難しくなる（テストは人間が見る前提）
見出した「領域」を評価単位とすることで、爆発を防ぐシステムの縦横構造検証対象・仕様記述対象として… 「具体機能」のみならず「概念」も必要

# どこからどう抽出・整理するか？ - 結論どこからどう抽出するか？ → Real Worldから、 BDDやDDDのプラクティスを使い抽出・整理する

# 自己紹介株式会社ログラスエンジニア依田啓佑 Keisuke Yoda x: kei_output_1104

Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール？〜

Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール？〜

Yoda Keisuke

More Decks by Yoda Keisuke

Other Decks in Programming

Featured

Transcript