What is JDA

経営とソフトウェアを「判断」でつなぐ

Judgement-Driven Architecture（JDA）は、
経営・ソフトウェア・AIをつなぐ「判断」のアーキテクチャである。

JDAが生まれたきっかけ

あるAIイベントに参加したときのことだった。
会場には、多くの企業ブースがあり、様々なAIサービスを紹介していた。

議事録を作る。
メールを書く。
情報を探す。
資料を要約する。

どれも便利だった。

実際、私自身も生成AIを日常的に活用しているし、その価値を否定するつもりはない。
しかし会場を歩きながら、ずっと同じことを考えていた。

「その後、人は何を判断するのだろう」

議事録ができたあと、何を決めるのか。
情報が集まったあと、何を選ぶのか。
メールが作られたあと、誰に送るのか。

企業活動を観察していると、

情報収集
↓
解釈
↓
判断
↓
行動（作業）

という流れで動いている。

AIサービスの多くは、情報収集や作業の支援を行う。
しかし、その先にある判断にはあまり触れていない。
時間短縮そのものは良い。
しかし、その時間で何を判断するのか。

そこが整理されなければ、本当の意味で企業の価値には繋がらないのではないか。

そんな違和感が、JDAを考え始めるきっかけになった。

では、企業は普段どのように判断しているのだろうか。

その問いから、私は改めて経営を見直してみた。

経営とは判断の連続である

経営には様々なフレームワークがある。

戦略を考えるフレームワーク。
業務を整理するフレームワーク。
事業を分析するフレームワーク。

一見すると別々のものに見える。
しかしよく見ていくと、それらが支援しているのは分析そのものではない。

何を選ぶか。
何をやめるか。
どこに投資するか。
誰に営業するか。

つまり意思決定である。

経営フレームワークの多くは、意思決定を支援するための仕組みとして見ることができる。

そう考えたとき、ひとつの疑問が生まれた。
もし経営の本質が意思決定にあるのだとしたら、その構造をソフトウェアとして扱うことはできないだろうか。

判断という共通構造

そこで考えたのが、

「経営フレームワークから、ソフトウェア工学の設計ができないか」

という問いだった。

そう考えると、企業活動をソフトウェアとして設計するためには、業務フローそのものではなく、その中にある「判断」を設計対象にすべきではないか。

そこから、JDAは生まれた。

JDAを構成する背景領域

JDAは、特定の一分野だけから出てきたものではない。

経営学、ソフトウェア工学、AI、制御工学、複雑系。
それぞれの分野に、似た構造がある。

共通する判断構造

一見すると別々の言葉だが、そこには共通する構造がある。

状態を観測する
↓
状況を解釈する
↓
判断する
↓
行動する
↓
結果が返る
↓
学習して次の判断を変える

これは、

• 経営で見れば意思決定
• ソフトウェアで見れば状態遷移
• AIで見れば判断支援と学習
• 制御工学で見ればフィードバックループ
• 複雑系で見れば適応

である。

JDAは、この共通構造を「判断」という言葉で束ね直したものである。

JDAは単なる比喩ではない

「経営は判断である」と言うだけなら、経営論で終わる。
「AIは判断を支援する」と言うだけなら、AI活用論で終わる。
「状態遷移で表せる」と言うだけなら、ソフトウェア設計で終わる。

JDAが目指しているのは、その先である。

判断を実装可能な構造へ変える

• 判断を抽出する
• 判断を構造化する
• 判断を実行する
• 判断ログを残す
• 妥当性を評価する
• 次の判断を改善する

つまり、JDAは「判断」を実装可能な構造として扱う。

JDAを構成する主要概念

そのために、JDAでは以下のような概念を使う。

• JP（Judgement Point）
  業務の中で発生する判断点。
• State
  判断によって変化する状態。
• Proposal / Case
  判断対象となる案件・実行単位。
• Judgement Harness
  判断を統一的に実行・記録するための共通基盤。
  判断そのものを交換可能・再利用可能な構造として扱う。
• JLog
  判断結果と判断理由を記録するログ。
• VLog
  その判断が妥当だったかを後から評価するためのログ。
• JJ（Judgement Journey）
  判断が連続して実行される流れ。
• Learning Cycle
  判断ログをもとに、次の判断を改善していく循環。

ここまで落とし込むことで、JDAは単なる思想ではなく、実装アーキテクチャになる。

AI時代に変わったこと

AI時代において、業務の自動化はどんどん簡単になる。

• メールを送る
• 文章を要約する
• 問い合わせに返信する
• PDFを読む
• データを抽出する

これらは、すでに当たり前になりつつある。

しかし、本当に難しいのはそこではない。

難しいのは「行動」ではなく「判断」

• 誰にメールを送るべきか
• 今送るべきか
• この問い合わせは重要か
• この顧客は優先すべきか
• この案件は進めるべきか
• この結果は妥当だったのか

つまり、難しいのは「行動」ではなく、その前にある「判断」である。

何も設計せずに、すべてを自動化することはできない。
少なくとも、責任ある業務ではできない。

だからこそ、AI時代には、業務自動化の前に判断設計が必要になる。

JDAにおけるAIの役割

JDAは、AIにすべてを任せるための理論ではない。

最初にやるべきことは、AIに判断させることではない。

まず、人間がどこで判断しているのかを明らかにする。
その判断に必要な材料を整理する。
判断結果と理由をログとして残す。
その判断が妥当だったかを後から評価する。

AIはまず判断材料を支援する

そのうえで、AIはまず判断材料の生成を支援する。

• 類似案件を出す
• 過去の判断を示す
• 候補を整理する
• リスクを提示する
• 判断理由の入力を補助する

判断材料の精度が上がれば、人間の判断は速くなり、安定する。

さらに JLog / VLog が蓄積されれば、AIは過去の判断を再現できるようになる。

判断材料学習 → 判断再現学習 → 判断委譲

そして最終的には、一定の条件下で判断をAIへ委譲できる可能性が出てくる。

つまりJDAのLearningは、次のように進む。

判断材料学習

↓

判断再現学習

↓

判断委譲

この段階性が重要である。

JDAの目的

JDAは、経営の意思決定論を、ソフトウェア工学の状態遷移と、AIの学習ループに接続した、判断の実装アーキテクチャである。

別の言い方をすれば、JDAは、企業の中にある判断を、実行可能で、記録可能で、学習可能な構造に変えるための考え方である。

AI時代の競争力は判断データになる

AI時代の企業にとって、本当に価値を持つデータは、単なる業務データではない。

• なぜその判断をしたのか
• どの材料を見たのか
• 誰が判断したのか
• その判断は妥当だったのか
• 次はどう判断すべきか

このような判断データこそが、企業固有の学習資産になる。

JDAは、その判断データを生み出し、活用するためのアーキテクチャである。

業務を自動化する前に、判断を設計する

業務を自動化する前に、判断を設計する。

これが、JDAの出発点である。