3秒でわかる
システムの中で何が起きたかを外から確かめられる性質。障害の原因追跡やAIの判断根拠の説明など、結果だけでなく過程を見せる設計を指します。
もう少し詳しく
どういうものか
透明性は、システムの内部で何がどう処理されたかを、外から観察し検証できる性質を指します。入力と出力だけが見えて途中が分からない状態を「ブラックボックス」と呼び、その反対の状態が透明性の高い状態です。
文脈によって具体的な中身は変わります。運用の文脈ではログやトレースが残っていること、AI の文脈では出力の根拠を示せること、組織の文脈では使っているモデルやデータの出所を開示していることを指します。
なぜ必要か
透明でないシステムは、壊れたときに直せません。エラーが出たのに、どの入力で、どの分岐を通り、どこで失敗したかが分からなければ、修正はあてずっぽうになります。
AI を業務に組み込む場面では、さらに重い意味を持ちます。融資の審査や採用の選考で「モデルがそう言ったから」は説明として通りません。EU の AI 法をはじめとする規制でも、生成物が AI 由来であることの明示や、学習データの概要開示が求められる方向に進んでいます。利用者の側も、根拠を示せる仕組みのほうを信頼します。
具体例
同じ処理でも、記録の残し方で追跡できる情報量が変わります。
import logging, uuid
logger = logging.getLogger(__name__)
def answer(question, user_id):
trace_id = str(uuid.uuid4())
docs = search(question)
logger.info(
"rag_search trace=%s user=%s hits=%s top_score=%.3f",
trace_id, user_id, len(docs), docs[0].score if docs else 0.0,
)
result = llm(prompt=build_prompt(question, docs))
logger.info("rag_answer trace=%s model=%s tokens=%s",
trace_id, result.model, result.usage.total_tokens)
return {
"answer": result.text,
"sources": [d.url for d in docs], # 根拠を利用者にも返す
"trace_id": trace_id,
}同じ trace_id を全ての記録に持たせることで、1 件の問い合わせの全経路を後から並べ直せます。
つまずきやすいところ
error occurred としか書かない行は、あっても追跡に使えません覚え方
「結果だけでなく、途中を見せられるか」で判断します。後から誰かに「なぜこうなったのか」と聞かれて答えられる設計なら、その部分は透明です。