AI開発ハーネス — AI駆動開発を実用にする

AIが変えるソフトウェア開発

AI開発の美点は、次のようなところにあります。

要求や仕様を自然言語で記述し、構想や業務知識を開発の出発点にできます。
簡潔な仕様から未記述の部分を推論・補完し、検討すべき前提や選択肢を明らかにできます。
既存システムや技術情報を探索し、必要な知識を設計と実装の候補に適用できます。
プログラムを圧倒的なスピードと規模で生成できます。
その結果、短期間に繰り返しプログラムを作り直し、異なる設計や実装を試せます。
曖昧な情報や状況の変化に応じる新しい応用へ踏み出せます。

AI開発の美点は、画面中心で業務規則や状態管理が比較的単純なWebアプリケーションで、早くから活かせる可能性があります。

業務アプリケーションに求められる条件と課題

中核的な業務アプリケーションでは、個々の機能に加えて、システム全体の規則と品質を揃える必要があります。

業務アプリケーションは、業務規則と不変条件 (Invariant)、認可、状態遷移、トランザクション (Transaction)、監査可能性を一貫して満たす必要があります。さらに、外部システムとの契約を守り、利用状況に見合う応答性能、信頼性 (Reliability)、可用性、セキュリティ (Security)、可観測性 (observability, オブザーバビリティ)を維持する必要があります。これらの条件はシステム全体と運用に及びます。

これらの条件を自然言語プロンプトとAIの注意力だけで継続的に満たすことは難しく、中核的な業務アプリケーションへの適用には大きな課題が残ります。

AIが簡潔な仕様を補いながら開発する場合、次の三つを区別して確認する必要があります。

開発効率：要求された変更を、手戻りを抑えて完成させられるか。
成果物の品質：AIが補った判断を含む変更が、業務上の正しさと必要な品質属性 (Quality Attribute)に適合しているか。
AI計算コスト：コンテキストの再構成、探索、再生成、再レビューをどこまで減らせるか。

候補生成だけを速くしても、不適切な前提や技術を適用した候補が増えれば、レビューと修正が増えます。品質をコンテキストの量だけで支えようとすると、毎回の再構成と推論に大きな計算が必要になります。

AIが補った判断と適用した技術をシステム全体の要求と照合するには、前提と検証条件を明示する必要があります。

AIが補った判断を仕様や設計として残さず、自然言語のやり取りとAIの注意力だけに依存 (Dependency)すると、対話履歴や参照情報が変わったときに同じ要求から異なる実装が生まれ得ます。処理手順や例外時の振る舞い (Behavior)まで毎回AIに組み立てさせる場合の設計上の問題は、後続回で具体的に扱います。

AI開発は、候補の生成から、採用できる変更として承認するまでに要する時間、計算、判断、手戻りで評価します。ここでは、その総量を収束コストと呼びます。

convergence flow

解決すべき問題は、AIが補完した内容と検証条件を明示し、不適切な候補を見分け、修正後に必要な再確認を限定できるようにすることです。

AI開発ハーネスによる対策

AI開発ハーネスは、AIへ与える意味、探索範囲、成果物の形式、状態変更の境界、検証方法、エビデンス、承認を構造化します。AIが推論で補った判断を確認し、業務規則に適合する候補へ探索を導きます。

要求とAIが補った判断をモデル (Model)や型付き意図として残すと、候補を同じ基準で機械的に検証し、業務上の意味をレビューできます。修正後は変更箇所と影響を受ける箇所を再検証し、その結果を承認の判断材料として残します。判断基準の再利用はレビューの手戻りを抑え、再検証の範囲を明確にすることは不要な探索や再生成に使うAI計算を抑えます。

ハーネスは、モデル、アーキテクチャ、型 (Type)、DSL (Domain Specific Language)、プログラム、ランタイム、テスト (Test)、レビュー、承認など、ソフトウェア工学の成果をAI駆動開発で活用できるタガです。その内側でAIを意図理解、探索、仮説、候補生成、説明などの得意分野と、AIでないと実現できない応用へ集中させます。

業務アプリケーション級の保証には、決定性、再現性、追跡可能性 (Traceability)が必要です。連載で扱う各ハーネスは、ソフトウェア工学の成果を入力、境界、成果物、検証として具体化します。

生成AI向けのスキル、ツール、指示、ガードレールのセットもハーネスの一形態です。しかし、本シリーズで扱うハーネスはそれより広い概念です。ハーネスは、モデルを作る場所、アーキテクチャ上の責務 (Responsibility)を決める場所、プログラムを記述する場所、ランタイムで実行する場所、結果を検証する場所、知識を参照する場所に、それぞれ異なる形で現れます。

開発の各場所にあるハーネスを組み合わせ、AIの解釈・推論・探索を業務規則、決定的実行、エビデンス、人間の承認へ接続します。この組み合わせが、業務アプリケーション級のプログラムをAIとともに開発するための基盤になります。

本シリーズは全10回です。第1回である本稿は、メリット、適用を妨げる問題、広義のハーネスという対策、共通語彙、シリーズ全体の構成を示します。第2回以降の9回では、モデル、アーキテクチャ、プログラミング、ランタイム、検証、知識に現れるさまざまなハーネスを取り上げ、それらを検証・改善のフィードバックループとして組み合わせる方法を提案します。

中心原則は次の二つです。

プロンプト (Prompt)は意図、モデルはプログラム。
非決定的に考え、決定的に実行する。

AIの非決定性は、意図の理解、質問、探索、仮説、候補生成、説明で活用します。一方、状態変更、業務規則、妥当性確認 (validation)、認可、永続化 (Persistence)、ワークフロー、再試行、冪等性、並行性、補償は、明示された意味を実行するプログラムとランタイムへ委ねます。

interaction execution boundary

ここで区別するのは、AIが解釈・探索・提案する段階と、承認済みの意味に従って状態を変更する段階です。どの責務に非決定性を許し、どの境界から決定的な実行を要求するかを明確にします。

シリーズで用いる技術とプロダクト

本シリーズでは、ハーネスの働きを具体的に示すため、以下の技術とプロダクトを使用します。

SimpleModeling (シンプルモデリング)：モデルを中心に設計・実装・実行をつなぐ開発方法論。
CML (Cozy Modeling Language)：モデルを記述する言語。
Cozy：モデルをプログラム・設定・文書へ変換するツール。
Textus：ソフトウェアの実行基盤。

変換規則だけで定まらない実装にはAIを活用します。

シリーズ全体の構成

シリーズは全10回、4部で構成します。

第I部問題設定（第1回）：なぜAI開発ハーネスが必要か。
第II部モデル空間を制約 (Constraint)する（第2～4回）：何をモデル化し、どの構造と振る舞いを許すか。
第III部実現空間を制約する（第5～8回）：責務、知識、実装、実行をどう制約するか。
第IV部実行から正本へ戻す（第9～10回）：エビデンスをどう評価し、人間の承認へ戻すか。

本シリーズの次には、Essenceフレームワークによる開発プロセス定義を扱います。

まとめ

AIは自然言語の仕様を推論で補い、技術情報を探して適用できます。その判断が要求に合うかは別途確認が必要です。
業務アプリケーションの正しさと品質は、明示した規則、検証、エビデンス、人間の承認で支えます。
全10回で、ソフトウェア工学の成果をAIが活用できるさまざまなハーネスと、その組み合わせを提案します。

次回

第2回「モデル・ハーネス」では、自然言語の意図を、人間とプログラムが確認できるモデル、型付き意図、コマンドへ具体化します。

参照

用語集

オブザーバビリティ (observability, 可観測性): Observabilityは、システムやドメインの内部状態を外部からの観測を通じて推論・理解できる性質を表します。単なるモニタリング可能性を超え、現象(Phenomenon)や観測記録(Observation)を一貫して収集・関連付け、ドメイン・イベント(Domain Event)として意味づけられることで、システムの挙動を総合的に把握できる状態を指します。
セキュリティ (Security): Securityとは、情報と機能を正当な権限に従って保護し、不正な閲覧、利用、変更、破壊、否認を防ぐ性質です。Confidentiality、Integrity、Authenticity、AccountabilityなどのConcernを含みます。
信頼性 (Reliability): Reliabilityとは、指定された条件と期間のもとで、システムが要求された機能を一貫して遂行する性質です。Availability、Fault Tolerance、Recoverabilityなどを含む観点から評価します。
不変条件 (Invariant): Invariantとは、対象が有効である間、観測可能な安定点で常に成立しなければならないConstraintです。Object、Type、または複数要素からなる構造に適用できます。
トランザクション (Transaction): Undefined
品質属性 (Quality Attribute): Quality Attributeとは、ソフトウェアが機能を実行できることに加えて、どの程度の品質で要求を満たすかを表す特性です。Security、Performance、Availability、Reliability、Resilience、Observability、Maintainabilityなどが含まれます。
仕様確認 (verification): Verification(仕様確認)とは、規定された設計仕様や要求仕様に対して、実装が一致しているかを確認する行為である。
依存 (Dependency): UMLにおけるDependencyは、ClientとなるModel Elementの仕様または実装が、Supplierとなる別のModel Elementの定義へ意味的または構造的に依存することを表すDirected Relationshipです。
振る舞い (Behavior): UMLにおけるBehaviorは、そのContextとなるBehaviored Classifierが時間とともにどのようにStateを変えるかを定める仕様です。可能な実行、創発する振る舞い、または特定の実行例を表せます。
モデル (Model): Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
テスト (Test): Testとは、指定した条件で対象を実行または評価し、観測した結果を期待する結果やConstraintと比較して、要求または契約への適合を確認する活動とその仕様です。
型 (Type): Undefined
DSL (Domain Specific Language): DSL（ドメイン固有言語）は、特定の領域（ドメイン）に特化して設計された言語であり、その分野の概念や構造を直接的かつ簡潔に表現することを目的とします。一般的な汎用プログラミング言語（GPL）に比べ、DSLは特定ドメインの問題解決や自動生成に適した高い抽象度を持ちます。
追跡可能性 (Traceability): 開発におけるTraceabilityとは、要求、用語、Model Element、設計判断、Test、実装、実行結果の関係を識別子と根拠によってたどれる性質です。
責務 (Responsibility): Responsibilityとは、ObjectまたはRoleが、何を知り、判断し、行い、守るべきかを表す義務です。構造上の情報だけでなく、規則とBehaviorの所有を定めます。
プロンプト (Prompt): RAGによって取得された知識を、AIモデルの推論プロセスに橋渡しするための構造化指示または文脈表現。 BoKに格納された構造化知識を、モデルが理解し行動・内化できる物語的／命令的形式に変換する。
永続化 (Persistence): Undefined
妥当性確認 (validation): Validation(妥当性確認)とは、システムや機能が利用目的や要求仕様に対して妥当であるかを確認する行為である。
状態 (State): UMLにおけるStateは、ある不変条件が成立している状況をモデル化したものです。Objectの現在のStateによって、受け付けられるEventやOperation、成立するConstraint、次に可能なTransitionが変わります。
シンプルモデリング (SimpleModeling): SimpleModelingは、KnowledgeからDomain Modelを構成し、CMLで形式化し、CozyとAIによって実行可能ソフトウェアへ実現し、Textus上で動作させる、モデリング中心のソフトウェア開発方法論と技術体系です。
Cozy Modeling Language (CML): CML（Cozy Modeling Language）は、オブジェクト・モデルのうち、プログラム生成と実行へ接続する実行可能モデルを記述するSimpleModelingの形式モデリング言語です。
Cozy: Cozyは、CMLと各種DSLで記述されたModelを解析し、プログラム、設定、文書などの実現成果物へ変換するSimpleModelingのツールチェーンです。
Textus: Textusは、SimpleModelingによって実現されたソフトウェアを動作させるための実行基盤です。アプリケーションに共通する実行、運用、連携の機構を提供します。
制約 (Constraint): UMLにおけるConstraintは、一つ以上のModel ElementのSemanticsの一部を宣言するため、自然言語または機械可読言語で表した条件または制限です。評価結果はBooleanであり、評価は副作用を持ちません。
実現関係 (Realization): Undefined