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 

29