よくある質問

ある操作の実行中に、許可されているかどうかの確認でひとつでも失敗した場合、その操作全体がそこで止まります。代わりの処理に切り替えたり、そのまま再試行したり、一部だけ実行したりすることはありません。AIのすべての操作は、実行される前に必ず「これをしてよいか」という確認を通過します。

いいえ。Fail-closedとは、「止まるべきときにきちんと止まる」という意味です — 許可の確認が失敗したときだけ、処理を止めます。そして、どこまでを「止めるべきとき」とするかは、御社側で定義や条件として設定できます。つまり、その境界をどこに置くかは、御社が決めることです。システムがランダムに止まるわけではなく、AIに任せてよい範囲の限界として御社自身が決めた場所で、正確に止まります。

いいえ。重要な判断がともなう場面では、必ず人間の確認を経るようになっています。AIが提案し、人間が承認する、という流れです。これは設定でオン・オフできる機能ではなく、仕組みそのものに組み込まれた決まりです。

Demand、Commitment、Fulfillment、Value、Financial、Relationship、Insight。すべてのビジネス活動はこの7つの意味の流れの構成です。

問いの立て方を変える必要があります。「どこまで任せられるか」ではなく、「どこまで安全に任せられるか」です。OS iXanagiでは、リスクの低い操作はAIが自律的に行い、リスクの高い操作は必ず人間の承認を必要とする、という形で、仕組みとしてはっきり分けられています。

実例があります。ある旅行代理店が全業務をAPI化しました – コンソールで照会できるデータはそのままAPIで照会可能です。このAPIをChatGPTのMyGPTに接続しました。結果は？全く役に立ちませんでした。

AIはデータを取得できました – ホテルの空室、予約記録、顧客履歴。しかし、そのデータを「理解」できなかったのです：なぜこのホテルはハネムーンには最適だが家族には不向きか、なぜこのツアーは桜の季節に日程変更が必要か、なぜこの顧客はいつも特定のガイドをリクエストするか。

これは全企業が直面する知識ギャップです。APIアクセスはAIにデータを与えます。Knowledge OntologyはAIに「理解」を与えます。

OS iXanagiのアクセス制御は、設定でオン・オフする機能ではなく、仕組みそのものに組み込まれた決まりです。誰が何をできるかは、組織全体の設定としてあらかじめ決められた一つのルールに基づきます。つまり、AIも人間の利用者も同じアクセスのルールに従います — AIだけの特別な権限の仕組みは存在しません。AIが何らかの操作を行おうとすると、その実行前に、必ずこのルールに沿っているかが確認されます。権限が無ければ、その操作は実行されません。

Dockerサービスとしてデプロイされるコンテナ化プラットフォーム。各テナントは共有インフラ上で分離されたデータを持ちます。

はい。OS iXanagiには8モジュールの移行パイプラインがあります：Import（ソース登録とクロール）、Extraction（AI分析）、Interpretation（意味抽出）、Candidates（レビューと承認）、Mapping（構造整合）、Apply（ドライラン付き実行）、Audit（変更前後の検証）、Post-Migration（カバレッジとヘルスチェック）。

WordPressサイトの場合、パイプラインがコンテンツと構造の両方の移行を処理します。サーバー変更は不要です – OS iXanagiはヘッドレスモードで開始でき、既存サイトを動かしたままAPIで接続できます。

いいえ。OS iXanagiはヘッドレスモードで開始できます – 既存のインフラに触れることなく、APIを通じて接続します。ウェブサイトはそのまま動き続けます。データも今の場所に残ります。OS iXanagiはその上にガバナンスと知識の層を追加し、御社のペースで移行を進められます。

はい、双方向で対応しています。取り込み：ExcelファイルがInbound Gatewayを通じて入り、AIが構造を解析し、意味のあるデータをMeaning Objectsに変換して業務フローに接続します。出力：AIエージェントがあらゆるドメインからデータを集計し、レポートを生成し、Insight Domainを通じてフォーマット済みExcelファイルを出力します。ガバナンス層がすべてのデータ変換を監査可能かつ可逆に保証します。

はい。OS iXanagiはAPIを前提とした設計です — コンソールの画面から行えるすべての操作は、APIからも同じように行えます。御社は、ガバナンスの仕組みをそのまま引き継いだ形で、独自の画面（フロントエンド）を作ることができます。権限やルールの確認は、どの経路から操作しても同じように適用されます — コンソールの画面上で人間がボタンを押しても、外部のシステムがAPIを呼び出しても、同じ確認と同じルールが適用されます。

コンソールはモバイルブラウザからアクセス可能です。AIチャットインターフェースはモバイルに特に適しています – 自然言語でAIエージェントに指示を出すことは、本質的にモバイルフレンドリーです。将来的にPWAやネイティブアプリのサポートを予定していますが、現在のブラウザ体験はモバイルで完全に機能しています。

OS iXanagiのセキュリティは、「後から機能を追加して守る」という発想ではありません。攻撃が成立してしまう構造そのものを、最初から作らないという考え方です。

3つの仕組みが組み合わさっています。

まず、すべてのデータの変更は、あらかじめ登録された決まった手続き（「これをしてよい」という宣言）を必ず通ります。登録されていない操作は、拒否されるのではなく、そもそも存在しません。

次に、AIにも最小限の権限しか与えません。AIは決められた範囲の操作しかできず、プログラムのコードを読んだり、サーバーに直接コマンドを送ったりすることはできません。仮にAIが何らかの方法で誤った指示を受けても、与えられていない操作はできないままです。

最後に、すべてのデータ変更は、実行される前に必ず人間に提示され、承認されるまで実行されません。AIが一人で判断してデータを変えることはありません。

さらに、お客様ごとのデータは、システムの中核部分で分けて管理されており、別のお客様のデータに触れる経路そのものが存在しません（詳しくは「テナント間のデータ漏洩は起こり得ますか？」をご覧ください）。

まとめると、OS iXanagiのセキュリティは「壁を高くする」のではなく、「許可されていない操作がそもそも起こりえない」という考え方で成り立っています。

いいえ。OS iXanagiではSQL Injection（データベースへの不正な命令の注入）はそもそも起こりえません。

一般的なシステムでは、プログラムがユーザーの入力をそのままデータベースへの命令文に組み込んで送信します。この組み込み方に不備があると、攻撃者は入力の中に悪意のある命令を混ぜ込むことができてしまいます。この弱点は、プログラムがデータベースに直接命令文を送れる作りになっていることから生まれます。

OS iXanagiは、この経路そのものを取り除いています。個々の機能のプログラムは、データベースへ命令文を直接書くことを禁止されています。データのやり取りはすべて、決まった手順を呼び出す形でしか行えません。この手順は、受け取った値を命令文の一部として組み立てる形ではなく、値と処理を分けて安全に扱う形で、内部的にデータベースへ届けます。

このルールは「書かないようにする」という注意事項ではなく、「書く手段そのものが存在しない」という作り方の話です。開発者が直接データベースに命令文を送ろうとしても、それができる経路が用意されていません。

結果として、どのような入力が送られても、それがデータベースへの命令として解釈されてしまう経路は存在しません。

OS iXanagiは、プロンプトインジェクションを複数の仕組みで封じ込めており、システムの中でも特に厳重に守られている部分です。

プロンプトインジェクションとは、AIが読み取るコンテンツの中に悪意のある指示を埋め込み、AIを誤作動させようとする攻撃で、AIを使うシステム全般に共通する既知のリスクです。OS iXanagiはこれを、入力内容をチェックするだけでなく、仕組みそのもので封じ込めることで対処しています。

データへの入口は一つだけ: AIが扱えるのは、あらかじめ決められたごく限られた手段のみで、それ以外の方法でデータにアクセスすることはできません。ファイルを読み取ったり、任意のコードを実行したり、データベースに直接触れたりすることはできません。

使える操作も厳しく制限: AIが実行の際に使える手段はごく一部に限定されており、それ以外のコマンドの実行はサーバー側で拒否されます。埋め込まれた指示がシステムに直接コマンドを実行させようとしても、実行の層が受け付けません。

できる操作そのものが決められている: それぞれのAIは、実行してよい操作の一覧をあらかじめ持っています。埋め込まれた指示がデータの削除を指示しても、そのAIに削除の権限が無ければ（そもそもOS iXanagiには削除の権限を持つAIはいません）、その操作は成立しません。

最後は人間の承認: プロンプトインジェクションによって、仮にもっともらしい変更案が作られたとしても、それが実行されるには人間の承認が必要です。この承認は自動処理ではなく、提案された変更を実際に人間が確認して行う操作です。

これらの備えは積み重なっています。AIは決められた手段の外に出ることができず、与えられた権限を超えることができず、人間の同意なしには何も実行できません。

いいえ。別のお客様のデータが混ざって見えてしまうことは、仕組みの作り方そのものによって防がれています。

一般的なシステムでは、プログラムのあちこちに「これはどのお客様のものか」を確認する処理が個別に書き込まれています。この確認をどこか1か所でも書き忘れると、別のお客様のデータが見えてしまう事故が起こり得ます。つまり、安全性が人の書き間違い次第になってしまうということです。

OS iXanagiでは、この「書き忘れ」がそもそも起こらない作りになっています。

まず、データの出し入れは必ずシステムの中核（Kernel）を一度経由します。個々の機能のプログラムがデータベースに直接触ることはできません。Kernelが自動的に「どのお客様のものか」を区別してから取り出すため、機能を追加するたびに区別の処理を書く必要がありません。

次に、蓄積した情報（Knowledge Object）を参照する経路も、何段階かを順番にたどる仕組みになっています。あるお客様の画面から別のお客様のデータへたどり着く道そのものが存在しないため、誤って表示されることはありません。

AI（AI Agent）が動く場合も同じです。AIが起動されるときには最初から「どのお客様の担当か」が組み込まれており、AI自身が別のお客様を指定してデータを取りに行く手段はありません。

唯一、すべてのお客様が共通で見てよい汎用的な情報（一般的な用語の説明など）だけが共有の場所に置かれますが、個々のお客様の業務データがそこに混じることはありません。

まとめると、この安全性は「運用で気をつける」ことで保たれているのではなく、「混ざる経路がそもそも存在しない」ことで保たれています。設定を変えると他のお客様のデータが見えてしまう、というような設定項目も存在しません。

いいえ。OS iXanagiは「権限は下へ行くほど狭まる一方で、広がることはない」という原則を採用しており、権限の昇格は仕組みとして起こりえません。

一般的なシステムでは、管理者権限を奪うことが攻撃者の最大の狙いです。管理者権限を奪われると、すべてのデータへのアクセスや設定の変更、裏口の作成まで可能になってしまいます。

OS iXanagiは権限を階層で管理しており、それぞれの階層は、上の階層が許した範囲を狭めることしかできません。広げることは決してできません。

・一番上の階層（運営者）が、全体の上限を決める ・お客様側の管理者は、その上限の中でさらに制限することはできるが、上限を超えることはできない ・ブランドや個々のサイトの単位でも、さらに制限することはできるが、昇格させることはできない

AIについても同じです。それぞれのAIには、できる操作の範囲があらかじめ決められています。お客様側の管理者は、AIの書き込み権限を無効にすることはできますが、運営者が読み取り専用と決めた範囲に書き込み権限を追加することはできません。利用するAIの性能についても、上位の設定でできることの範囲内でしか変更できません（例えば、より高性能なモデルへの変更はできず、より簡易なモデルへの切り替えのみ可能、といった形です）。

ですから、お客様側の管理者アカウントが乗っ取られたとしても、攻撃者は

・運営者側の設定には触れられない ・決められた制限の範囲を超えて権限の定義を変えられない ・他のお客様のデータにはアクセスできない（データは最初から分けて管理されています） ・人間の承認を必要とする仕組みを回避できない

という状態のままです。

OS iXanagiは、構造的な防止と、詳細な記録の両方を組み合わせて、データの不正な改ざんに対応しています。

人間の承認による防止: AIや自動処理は、人間の承認なしにデータを変更することはできません。すべての書き込み操作は、変更案の提示 → 承認、という流れを必ず通ります。この承認は内部的なフラグではなく、画面上で人間が実際に行う操作です。内部の処理の一部が何らかの形で乗っ取られたとしても、気づかれないままデータを書き換えることはできません。

重要な情報は専用の承認フローを通る: OS iXanagiの中でも特に重要なデータ（蓄積された知識やルール）への変更は、専用の提案・承認の流れに従います。AIやアプリが変更案を出すと、それが確認の一覧に表示され、人間がその内容を確認して、受け入れる・却下する・修正するかを判断します。この判断の履歴は、ずっと記録として残ります。

すべての操作を記録: AIが行った操作は、誰が・いつ・どこで始めたか、どのようなやり取りがあったか、そして変更の前後の内容を、すべて記録として保存します。

検出と復旧: 記録を確認して不正な変更が見つかった場合、変更前後の内容の記録から、元の状態に戻すために必要な情報がそのまま得られます。蓄積された知識については、変更の経緯がすべて履歴として残っています。

さらに、OS iXanagiにはデータを削除する権限を持つAIが一人もいません。削除は、画面上で人間が直接行う操作に限られています。つまり、AIの側が何らかの形で完全に乗っ取られたとしても、データを破壊することはできません。

なお、データベースの定期的な保管（バックアップ）や、保存データの暗号化、通信の暗号化といった基盤レベルの保護は、これらアプリケーション側の仕組みを補う形で、インフラの運用側で別途管理されています。

OS iXanagiは、よくある攻撃の手口に対して、後から直すパッチではなく、そもそも成立しない作りで対応しています。

主な備えは次のとおりです。データベースへの不正な命令の注入（SQL Injection）を仕組みとして排除していること、外部から正規の手続きを経ずにシステムを呼び出せないこと、乗っ取られたアカウントが上位の権限に昇格できないこと、AIへの悪意ある指示（プロンプトインジェクション）を複数の仕組みで封じ込めていること、お客様同士のデータが混ざらないようになっていること、そしてデータの不正な書き換えを防ぎ・追跡できることです。

それぞれの詳しい内容は、以下の各項目で説明しています。すべてに共通しているのは、たとえ何らかの形で侵入されたとしても、意味のある不正な操作は成立しないということです。あらかじめ決まった手続きだけが実行を許され、AIは与えられた範囲しか動けず、すべての変更は人間の承認を必要とするからです。

いいえ。OS iXanagiには「隠れたAPI」はそもそも存在できません。

一般的なシステムでは、外部から呼び出せる窓口（API）がURLなどの形で用意されています。攻撃者は、こうした窓口を手当たり次第に調べたり、公開されていない管理用の窓口を見つけ出したりすることで、忘れられていた窓口や保護されていない窓口を突いてきます。

OS iXanagiには、そうした従来型の「URLの窓口」という形自体がありません。すべての操作は、あらかじめ名前を付けて登録された決まった手続きとしてのみ存在します。システムの中核部分は、この登録簿に載っている手続きしか扱いません。登録されていない操作を呼び出そうとしても、安全側に拒否されます。

つまり、 ・想定外の経路を生み出すURLの仕組みがそもそも無い ・外から直接触れる窓口が無い ・正規の手続きを迂回する「管理者モード」が無い ・すべての操作は、誰が・何に対して・どのような条件で実行してよいかを明示して登録されている

ということです。攻撃者が手続きの名前を推測できたとしても、何も得られません。登録簿は名前が存在するかどうかだけでなく、呼び出した側が本当にその操作を行ってよい立場にあるか（誰の、どの範囲のものか、本人確認が取れているか）も必ず確認するからです。