All Posts

What is accountability-relevant information in the age of AI? When AI decisions enter society, accuracy alone is not enough. Even if an AI output appears correct, accountability becomes difficult if we lose information about where the judgment came from, what grounds supported it, who or what was involved, what had been verified, and what remained unverified. The Responsibility OS is an information infrastructure for addressing this problem. This article defines the Responsib

はじめに 「責任OS」は、AIの判断が実世界に作用するときに、後から責任状態を監査・検査・検証できるようにするための情報基盤として提案している概念です。 この概念を支える語のすべてが新しいわけではありません。情報学には、すでに来歴（provenance）、追跡可能性（traceability）、監査証跡（audit trail）、メタデータ（metadata）といった、近い概念が存在します。一方で、「責任情報」「責任状態」「非可換性」「可換化」「情報欠落」といった語は、これらの既存概念を責任OSの観点から束ね直すために、こちら側で立てた語です。 この用語集の目的は、この二つを混同せずに整理することです。どの語が既存の標準語で、どの語が責任OS独自の再定義語なのかを明示することで、責任OSの主張がどこまで既存の情報学の上に立っており、どこから新しい主張なのかを、読者が判断できるようにします。 なお、責任OSの数理的な核は、Lean 4による形式証明として responsibility-os-kernel で公開しています。この用語集の各語が、その形

AIの判断が社会の中に入っていくとき、問題になるのは、判断の精度だけではありません。 たとえAIの出力が正しそうに見えても、その判断がどこから来たのか、何を根拠にしたのか、誰が関与したのか、何が確認され、何が未確認だったのかが失われてしまえば、後から責任を確かめることができなくなります。 責任OSは、この問題を扱うための情報基盤です。 この記事では、責任OSを情報学の言葉で定義するために、まず中心となる用語を整理します。 ▼責任os リポジトリ https://github.com/GhostDriftTheory/responsibility-os-kernel 責任OSの中心概念は、責任情報です。 ここでいう責任情報とは、実世界の判断、作用、状態遷移について、後から責任状態を監査、検査、検証するために失ってはいけない情報を指します。 そこには、来歴、監査証跡、追跡可能性、関与者、権限、根拠、確認状態、未確認条件、順序、場所、影響範囲、不可逆性が含まれます。 英語では、まず accountability-relevant informati

開発者・提供者・利用者をまたぐ責任経路を、後から検査できる形で残すために AIの活用は、すでに実験段階を超えています。 業務システムに組み込まれ、顧客対応に使われ、審査や判断の補助にも入り始めています。その一方で、AIが関わった判断について、あとから「誰が、何を根拠に、どこまで確認したのか」を説明できる状態を作ることは、まだ多くの現場で難しいままです。 ここで重要になるのが、総務省・経済産業省の「AI事業者ガイドライン」です。 同ガイドラインは、AIの開発、提供、利用に関わる事業者が、AIのリスクをライフサイクル全体で捉え、必要な取組を自主的に進めるための指針です。細かな義務を一つずつ課すルールではなく、AIを安全に活用するために、事業者自身が考え、運用し、継続的に見直していくための枠組みだといえます。[1] だからこそ、問題は「ガイドラインを読むこと」では終わりません。 本当に必要なのは、ガイドラインが重視する考え方を、現場で扱える形に落とすことです。そのための設計思想として、責任OSが重要になります。 ▼責任OS　リポジトリ...

The Hiroshima AI Process sets out an international direction for safe, secure, and trustworthy AI. Its message is not simply that AI should be used carefully. It asks developers, deployers, and organizations to identify risks, assess them, reduce them, document what has been done, and make AI systems explainable and reviewable across their lifecycle. In other words, the Hiroshima AI Process is not only about using AI. It is about using AI in a way that can be checked later. T

広島AIプロセスは、生成AIを含む高度なAIシステムについて、安全で、信頼でき、人間中心のAIを実現するための国際的な枠組みです。 そこで求められているのは、単なる理念ではありません。 AIの開発、導入、運用の各段階でリスクを見つけること。必要な対応を取り、その内容を説明できる状態にすること。問題が起きたときに、どこまで戻って確認できるかを明らかにすること。 つまり、広島AIプロセスは、AIを「使う」だけでなく、AIを「後から確認できる形で使う」ことを求めています。 では、その要請を現場でどう支えるのか。 この問いに対して、GhostDrift数理研究所は「責任OS」という考え方を提示しています。 責任OSとは、AIの出力だけを見るのではなく、その判断がどの操作を通り、どの根拠に支えられ、どの責任経路をたどったのかを、後から確認できる形で残すための基盤です。 ▼責任OS　リポジトリ https://github.com/GhostDriftTheory/responsibility-os-kernel 広島AIプロセスが求めているもの...

AI makes responsibility boundaries harder to see As AI systems become involved in social and organizational decisions, one question becomes increasingly important: Who is responsible, for what decision, and up to what point? This is the problem of responsibility boundaries. In traditional operations, responsibility can often be arranged through contracts, workflows, approval rules, and organizational roles. A person reviews a document. A manager approves it. A company accepts

責任分界は、AIで曖昧になる AIが社会の判断に入り込むほど、「責任分界」という言葉が重要になります。 責任分界とは、誰が、どの判断に、どこまで責任を持つのかを切り分けることです。 従来の業務では、担当者、承認者、委託先、提供者、利用者の責任範囲を、契約書や業務フローで整理してきました。 しかしAIが判断に関わると、この線引きは曖昧になります。 AIが出した判断なのか。人間が確認した判断なのか。どの根拠を見たのか。どこから先が導入企業の責任なのか。どこから先が提供者の責任なのか。 結果だけが残っても、そこに至る過程が残っていなければ、責任分界は後から確認できません。 ▼責任OS リポジトリ https://github.com/GhostDriftTheory/responsibility-os-kernel 必要なのは、責任を自動で決めるAIではない ここで重要なのは、責任OSが「法的責任を自動で決める仕組み」ではないという点です。 責任OSが扱うのは、誰が悪いかを機械的に判定することではありません。 その前段階として、どの判断が、どの根拠に基

Around 10:40 a.m. Japan Standard Time on June 10, 2026, I searched Google for “RESPONSIBILITY OS” and observed that Responsibility OS was being displayed as a concept related to AI governance. Responsibility OS refers to the idea that AI judgment results, the conditions behind those judgments, audit traces, and responsibility records should not be separated from one another. As AI systems become more deeply embedded in society, the key question is no longer only “What answer

2026年6月10日10時40分頃（日本時間）、Google検索において「RESPONSIBILITY OS」と検索したところ、Responsibility OSがAIガバナンスに関する概念として表示されていることを確認しました。 Responsibility OSとは、AIの判断結果だけでなく、その判断に至った条件、監査証跡、責任記録を切り離さずに扱うための考え方です。 AIが社会実装されるほど、重要になるのは「AIが何を答えたか」だけではありません。その判断が、どの条件のもとで行われ、どの記録と結びつき、後から誰が検査できるのかが重要になります。 今回の表示は、検索順位や検索結果そのものを成果として誇るものではありません。検索結果は、地域・時刻・利用環境によって変動します。 ただし、2026年6月10日10時40分頃（日本時間）の時点で、「責任OS / Responsibility OS」という概念が、日本語圏だけでなく英語圏の検索空間にも接続され始めていることを確認したため、初期の観測記録として残しておきます。 GhostDrift数理研究

1. 自律型AIで増えるのは、「答え」ではなく「確認待ち」である AIは、申請書を読み、候補を出し、要件を整理し、比較表を作れるようになっていく。 しかし、現場で本当に問題になるのは、AIが答えを出せるかどうかではない。 問題は、その答えを受け取った審査官が、こう思うことだ。 「よさそうだが、自分で一から確かめ直さないと使えない」 自律型AIが進むほど、AIが出す候補や判断は増える。しかし、その判断に根拠・要件・確認履歴が付いていなければ、審査官の確認負担はむしろ増える。 ADIC/責任OSが解くのは、この問題である。 2. 審査官が止まる理由は、「怖い」よりも「確かめ直しが重い」こと 審査官は、AIの判断を最初から否定したいわけではない。むしろ、使えるなら使いたい。 しかし、AIが「この申請は通りそうです」「この企業が候補です」「この条件に合っています」と言っても、その根拠が見えなければ使えない。 審査官は結局、 どの要件を見たのか どの資料を根拠にしたのか どこが適合しているのか どこが未確認なのか なぜ別の候補ではないのか を自分で確かめ直

When AI systems are deployed in society, the central question is not only what answer the AI produced. We also need to know: - under what conditions the judgment was made, - what grounds supported it, - what audit traces remain, - and who can inspect what, after the fact. If these elements are separated from the AI judgment, the output may still look valid on the surface, while becoming difficult or impossible to inspect later. At GhostDriftTheory, we define the concept of Re

AIを社会実装するとき、本当に問題になるのは「AIがどんな答えを出したか」だけではありません。 その判断が、どの条件で行われたのか。何を根拠にしたのか。どの証跡に支えられているのか。誰が、どこまで確認できるのか。 ここが切り離されると、AIの判断は一見もっともらしく見えても、後から検査できないものになりえます。 弊社では、この問題を扱うための考え方として、責任OS という言葉を定義します。 ▼責任OS（Responsibility OS Kernel） Lean4リポジトリ https://github.com/GhostDriftTheory/responsibility-os-kernel 責任OSの定義 責任OSとは、AIの操作・判断・監査証跡・責任記録・判断根拠を、切り離さずに運ぶための基盤構造です。 ここでいう「責任OS」は、Windows や Linux のような通常のコンピュータOSを意味するものではありません。 AIが何かを判断したときに、判断結果だけを残すのではなく、その判断を支えた条件、証跡、根拠、責任記録を一体として扱い、

This Lean 4 formalization machine-checks that if AI governance requires judgment grounds to remain distinguishable, then a faithful evidence layer is structurally necessary. — - The Intuition A medical AI recommends “prioritize this drug.” Only the result is recorded. But was the decision based on blood test values, prior conditions, or a physician’s override? If that information is gone, safety verification after the fact is impossible. This Lean formalization says: the prob

一番シンプルに言うと 冷蔵薬を運ぶAIが「この道で運べ」と決めた。でも薬がダメになった。 このとき、「温度を見て決めたのか、渋滞を見て決めたのか、誰が確認したのか」が残っていなければ、原因も責任者もわからない。 だから命や安全に関わる場所では、AIの「答え」だけでなく「理由・証拠・確認者」まで一緒に残す仕組みが必要になる。 このLeanは、その仕組みが数学的に意味のある骨格を持つことを、機械検証したものです。 リポジトリ： https://github.com/GhostDriftTheory/adic-ai-assurance-lean 何を前提にしたか 前提の大枠は一つですが、その中にいくつかの構造を置いています。 「AIの動きだけを見るのではなく、その判断理由・証拠・責任記録も一緒に追える世界を考える」 具体的には次の構造を置いています。 O：AIが実際にやる操作の世界（「この道で運べ」「この薬を優先」といった判断） F：その操作に紐づく証跡のまとまり（温度センサーの値、血液検査の結果、確認した担当者など） E = ∫_O...

The Core Problem When AI is deployed in society, performance is not the only question. What conditions did the decision pass through? What evidence did it leave behind? Who can verify it afterward? The essence of AI assurance is whether we can say not “please trust us,” but “this can be checked.” Yet there is a deeper question. AI is a technology that can turn human beings into “data, scores, thresholds, and optimization targets.” Once an objective function such as “because i

問題の核心 AIが社会に実装されるとき、問われるのは性能だけではない。その判断が、どの条件を通り、何を証跡として残し、後から誰が検証できるのか。「信じてください」ではなく「確かめられます」と言えるか。これがAIアシュアランスの本質だ。しかしもっと深い問いがある。AIは、人間を「データ・スコア・閾値・最適化対象」へと変換しうる技術だ。「便利だから使う」「精度が高いから通す」という目的関数が成立した瞬間、その外にある尊厳・例外者・説明不能な痛み・未来世代が、判断構造の外へ落ちていく。核兵器とAIは同じ技術ではない。しかし両者は同じ層にある――人類が初めて、自分の存続条件を自分の技術で壊しうると自覚した層として。強い技術が人間を目的関数の中の対象へ変換し、その外にある尊厳・例外者・未来世代を判断構造の外へ落としうる、という構造的な接続がそこにある。核は都市と人間を「威力・半径・戦略効果」へ変換した。AIが人間を計算対象へ変換するとき、同じ構造が別の文脈で現れる可能性がある。 ▼リーン証明 👉 https://github.com/GhostDrift

日本企業の99.7%を占める中小企業。そのサイバーセキュリティ対策は、個社が自助努力のみで対応できる範疇を大きく超えつつある。資金や専門人材が限られる中小企業に対し、高度なゼロトラストアーキテクチャの構築・運用を求めるのは、構造的に極めて困難である。実際にSophosの調査（2025年版）では、サイバー被害の要因として「スタッフや技術・スキル不足」を挙げた企業が63%に達している。経済産業省の「サプライチェーン強化に向けたセキュリティ対策評価制度」は、中小企業が限られたリソースの中で必要な対策を判断しやすくする制度として設計されている。これは、個社の努力だけで高度な対策を完結させることの難しさを、公的制度側も前提にし始めていることを示している。では、日本の中小企業、ひいては日本の産業基盤の実効的な防衛力をいかに高べきか。 解決策の一つとして、中小企業が依存するシステムやITツールを提供する「システムベンダー」側が、致命的な破壊操作を実行前に止めるゲートを標準機能として装備することの必然性が高まっている。 ▼ADICサイバーアシュアランスのプレスリ

GhostDrift数理研究所では、金融機関向けの ADIC Cyber Assurance Demo を公開しました。 ▼デモ https://ghostdrifttheory.github.io/adic-cyber-assurance-demo/ ▼プレスリリース https://prtimes.jp/main/html/rd/p/000000003.000182721.html 何を見せるデモか このデモの主眼は、AIエージェントが出した指示を、そのまま金融システムの実行権限にしないことです。たとえば、攻撃者に操作された金融AIが、 外部口座を追加する 送金限度額を引き上げる 高額送金を実行する といった連鎖的な操作を試みた場合でも、ADIC Cyber Assurance は、実行前に証拠チェーンを検証します。証拠が揃わなければ、そのAI指示は銀行操作として実行できません。 Compromised AI Instruction -> ADIC Execution Gate -> NOT EXECUTABLE copy 普通のログ監視

Note: This article is a strategic and technical supplementary commentary on the recently published Lean 4 formal proof of the ADIC Cyber Assurance Extension by the GhostDrift Mathematical Institute. Please note that the official press release has been issued in Japanese only. You can access the Japanese press release here: [Insert Link to Japanese Press Release] Japan is a nation that has historically built global trust on its relentless commitment to the "quality of infrastr