Decision Logsについて
Decision Logsとは
Decision Logsは、AIを業務に通す前に、 業務単位で「判断・停止・責任・説明」の前提構造を、 外部から確認・整理・記録する、納品型のサービスです。
扱うのはAI導入後の運用ではなく、導入前の前提です。 ツールを選ぶ支援でも、業務を設計し直す支援でもありません。
このサービスの立ち位置
AI業務に関連する議論は多い。Decision Logsはその手前を扱う。
AIを入れる方法ではなく、AIを通す前提を確認する
AIを業務に活用する議論の多くは、ツール選定・精度評価・実装後の運用から始まる。Decision Logsが扱うのはその前にある問いだ。
AIを業務に通す前提構造が、現時点でどのように置かれているかを確認します。ツール選定が決まる前の段階から使えます。
AIの出力ではなく、業務の構造を見る
AIの出力精度やモデルの技術的検証は、このサービスの対象ではありません。Decision Logsが確認するのは、業務の側にある構造です。
AIが業務の途中に入ったとき、誰が最終判断を持つのか。どこで止めるのか。問題が起きたとき後から第三者に説明できるのか。これらは業務構造の側で置かれていなければならない。
改善を提案するのではなく、現在地を記録する
現状分析から改善提案・運用設計を行うのは、このサービスの役割ではありません。現在の業務構造を観測し、あるがままに記録することに役割を限定します。
存在しないものを、存在するように書きません。未定義のものは、未定義として記録します。
判断を代替するのではなく、判断できる事実構造を整理する
法的妥当性・監査適合の断定、判断の代行は行いません。Decision Logsが整理するのは、法務・経営・外部機関がそれぞれの立場で判断するための事実構造です。
現時点の観測範囲での記録として、事実の状態を示します。
納品型であることの意味
このサービスは、継続的な監視・体制組み込み・定期報告を前提としません。観測・記録が完了した時点で、役割が終わります。
- 時点の記録が手元に残る 確認した時点の業務構造が記録として納品されます。後から「当時何が置かれていたか」を参照できます。
- 外部の視点を分離できる 内部スタッフが観測者を兼ねないため、自己評価との混同が起きません。現場・法務・経営が同じ記録を基点に確認できます。
- 段階的に依頼できる STEP1のみの単独依頼が可能です。全STEPを一括で進める必要はありません。
- ツール選定前から使える AI導入の議論が具体化する前の段階から依頼できます。何も決まっていない状態でも、観測の対象になります。
- 継続的な依存が生まれない ツールや体制に組み込む前提を持ちません。納品をもってサービスの役割は完了します。
- 後から確認するための参照材料として使える 法務・経営・外部機関に対して、事実ベースの確認記録として提示できます。 ※法的妥当性・監査適合の保証ではありません。
扱わないもの
- AIツールの選定・PoC・実装・導入後の運用支援
- 業務プロセスの改善・再設計
- AIアシュアランスの提供・認証取得支援
- AIガバナンス体制の構築支援
- 業務運用・意思決定・承認の引き受け
- 法的助言・適法性判断・監査判断の代替
- 制度・規制への対応可否の見解
- 継続的な外部監視・安全性の保証
背景にある考え方
このサービスは、「AIは精度で壊れない。構造で壊れる。」という観点から設計されています。
止まれない設計のまま業務が動き続けることが、後から問題になる。その観点で、判断・停止・責任・説明の4点を観測対象として定めています。
AIが業務の途中で何かを判断したとき、後から「なぜその判断をしたか」を説明できる状態にするには、記録を残す手段よりも先に、何を記録として残すべきかを業務の側で整理しておく必要があります。証拠化ツールや監査基盤が有効に働くには、前提となる業務条件が整理されていることが重要です。Decision Logsは、その前提を業務単位で観測・整理・記録します。
この考え方を3つの段階で設計しています。まず業務の現在地を観測する（STEP1）。次にSTEP1で未定義だった箇所を依頼者が確認・決定し、その配置をDecision Logsが記録する（STEP2）。その上でAIを通す前提条件を業務単位で整理する（STEP3）。
この方法論をDecision Logs Method™と呼んでいます。