データ・文書・入出力

文書・表・画像・音声の入出力

53件の公開項目

• EA · EA-027業界別版業界別AI運用は、共通のAI統制を業界ごとに作り直すことではない。共通Coreの上に、適用法令・規制主体、保護データ、用途、意思決定や物理的影響、専門家監督、変更管理、証跡をIndustry Profileとして重ねる。同じ医療・金融・教育という名称でも、組織の法的地位、地域、データ、用途によって必要な統制は変わるため、業界名だけで可否やリスクを決めない。
• EA · EA-028AI教育・社内導入カリキュラム社内AI教育は、全員へ同じ製品操作を教えるだけでは不十分である。共通Coreを維持しつつ、利用者のrole、technical knowledge、扱うdata、task impact、利用するsystemに応じて学習到達点を分ける。受講完了と安全に業務利用できる能力は分離し、知識問題だけでなくsafe/unsafe input判別、source verification、confidential-data handling、exter
• EA · EA-029Enterprise AI運用テンプレート集運用テンプレートはAI統制を自動的に成立させるものではなく、判断・証拠・変更・未解決事項を再現可能に残すための器である。共通Coreを用意しつつ、法域・業界・組織・providerに応じて項目をtailorする。PASS/完了の記入だけでなく、根拠となるsource、eval、承認、readbackを結び付ける。
• EA · EA-072Vision／Video AI大全「Vision AIは単一能力ではない。OCR、検出、localization、caption、visual reasoning、retrieval、moderation、video temporal analysisを能力単位で評価し、model/API revisionとsource locatorを保持する。専用Vision APIのstructured detector outputとMLLMの自然言語理解は補完関係にあり、片方
• EA · EA-073Forms／Handwriting／Barcode AI「紙帳票をAIへ取り込む処理はOCRだけではない。文字認識、キーと値の対応、チェック状態、手書き判定、バーコード形式とpayload復号を別々に検証する必要がある。読み取れた文字やQRコードは、それだけで業務上の真正性や安全性を保証しない。原画像と抽出結果のprovenanceを保持し、正規化・検証・認可・必要な人手確認を後段に置く。」
• EA · EA-074Translation／Localization AI「企業向け翻訳AIは、モデルの一般翻訳品質だけで選ばない。用語資産の適用方式、言語ペア・modeごとの可用性、locale処理、監査可能なversioningを独立して確認する。TranslationとLocalizationは重なるが同一ではなく、自然な訳文が正しいlocale実装を保証するわけではない。」
• EA · EA-076Time Series AITIME_SERIES_OPS_EVAL_V1. Keep forecasting, anomaly detection and predictive-maintenance decisioning distinct, with timestamp/data-quality/calibration/regime context and baseline comparison.
• EA · EA-100日本語・日本業務特有のAI問題 — 敬語、縦書き、和暦、帳票、住所、人名、表記揺れ、日本語OCRを「日本語対応」の一語で潰さず、業務データ型・文書レイアウト・文字体系・社会言語的適切性ごとに検証する「日本語を生成できることと、日本の業務データを正確に処理できることは別である。住所の表記揺れ、人名の異体字、縦書きや帳票レイアウト、和暦、敬語などは独立した失敗条件を持つ。重要項目は生成モデルのもっともらしさだけで確定せず、公的・業務上の参照データ、決定的な変換規則、文書種別ごとの評価、人による訂正を組み合わせる。」
• EA · EA-101AI規制・標準Crosswalk「NIST AI RMF、ISO/IEC 42001、EU AI ActはAIリスク管理に関係するが、任意フレームワーク、管理システム規格、法令であり、相互に同等ではない。」
• EA · EA-213Unstructured／Document ETLUnstructuredは文書を要素へ分解し、その要素からRAG向けchunkを構成するOSS部品を提供する。抽出方式や依存によって読み順・表・来歴の結果が変わるため、元素材に照合した評価と権限継承を経てindexへ投入する。変換の成功だけで正確性や無通信性を判断しない。
• EA · EA-214DoclingDoclingはPDF、Office、画像等を共通構造へ変換し、Markdown・HTML・JSON等へ出力する。表・読み順・OCRの品質は素材と設定に依存するため、元素材との照合を行う。内部表現のJSON保存は変換後の構造を保持する手段であり、原文の完全復元や正確性の保証ではない。offline運用にはモデル準備と通信制御を別途確認する。
• EA · EA-215LlamaParse／高精度Document Parsing APILlamaParseはtier・versionを選び文書を構造化する専用APIです。素材の複雑さに応じたtier選択と、ページ・表・数値・来歴の評価を分けます。job完了だけで全ページ成功と判断しません。
• EA · EA-217DeepgramDeepgramの音声対話では、API世代・model・入力形式を固定し、文字列の確定、発話終了、生成、実再生、業務操作の認可を分けて管理する。
• EA · EA-218ElevenLabs Audio／Voice AgentsElevenLabsのTTS・STT・dubbing・sound・Voice Agentはmodelと製品ごとに評価し、接続権限、声素材の権利、商用条件、再生と保持を分ける。
• EA · EA-220Telephony API × Voice Agent電話向けVoice Agentでは、番号・SIP・call leg/media stream、providerごとのcodec、実再生/破棄、認証、human handoffをAIモデルから分けて確認する。
• EA · EA-238PII検出・匿名化・Redaction部品PII検出器とredaction/anonymization処理は、入力から識別子を見つけて変換するための部品であり、それだけで「匿名化済み」「規制適合」「再識別不能」を保証するものではない。検出対象、言語、文脈、データ形式、しきい値、変換方式、復元鍵・対応表、ログやキャッシュなどの残存コピーを分けて設計・検証する。
• EA · EA-240Structured Output／Schema ValidationStructured OutputやJSON Schemaは、LLM出力を機械処理しやすい構造へ制約し、parse/schema failureを減らすための境界です。schema適合を、内容の真偽、業務妥当性、認可、最新状態、副作用の安全性と同一視しません。
• EA · EA-004非LLM AI総合編 — OCR、画像認識、音声認識・合成、翻訳、埋め込み、reranker、分類・回帰・異常検知、画像/動画等の専用AIを、LLM中心の会話/生成系と混同せず運用契約・評価器・実行基盤で整理するためのprovider-neutral taxonomy「『非LLM AI』は、古いAIや小さなモデルだけを指す言葉ではない。企業システムではOCR、音声認識、音声合成、画像認識、翻訳、埋め込み、reranker、分類・回帰・異常検知など、特定の入力を特定の型の出力へ変換する専用AIが今も独立した運用部品として使われる。これらの内部実装はLSTM、Transformer、NMT、場合によってはLLMを含み得るため、『LLMかどうか』と『専用部品かどうか』は別に確認する。選定時に重要なのは、入
• EA · EA-237DLP／CASB／SSEで生成AI利用を統制するDLP/CASB/SSEは生成AI利用の可視化、data classification、access control、inline block/redactionを強化できます。ただし「DLP導入済み」を、すべてのprompt、response、file、tool、MCP経路が保護されている証明として扱いません。
• EA · EA-248CDCでAI Knowledgeを更新するChange Data Capture（CDC）は、databaseの変更をAI/RAG knowledgeへ低遅延で届ける経路として利用できます。ただし、CDCを導入しただけでsource databaseからretrieval indexまでexactly-onceに一致するわけではありません。 CDC transportと、document/chunk/embedding/search indexへのmaterialization
• EA · EA-1011AI Use-Case Coverage「Enterprise AIの用途管理では、Actor、Task、Function、Sector、Modality、Autonomy、Riskを分離して用途プロファイル化すると、単一カテゴリでは失われる利用コンテキストと統制要件を追跡しやすい。これはNIST AI RMFのcontext mappingおよびOECDの多次元AI分類と整合する運用設計であるが、両機関がこの七軸schema自体を標準として規定しているわけではない。」
• EA · EA-1012AI Use-Case Coverage Census／未充足セル・過密セル検出「Coverage Censusは、version固定した多軸プロファイル上でEA・実運用ユースケースの分布を観測し、未充足・過密・分類不能を探索する。空セルは自動的に不足や新規導入必要性を意味せず、過密セルも自動的に重複を意味しない。各signalは用途、actor、risk、evidence、代替手段を確認してdispositionする。」
• EA · EA-1202Training-data Production／Curation／Annotation／Split Governance「データを大量に集めれば性能が上がる」「重複排除すればprivacy問題が解決する」「annotation agreementが高ければ正解」「train/testを分ければcontaminationはない」と一般化しません。
• EA · EA-1204AI Intervention Feedback Loops／Performative Prediction／Selective Labels「再学習すればfeedback loopは解消する」ではなく、「AIの予測や業務判断が次の観測データを変える場合、通常の再学習は過去policyの選択を再生産する可能性がある。decision/exposureとlabel availabilityを記録し、performative shift、selective labels、外生的shiftを分離して評価する」と記述します。
• EA · EA-1205Model Privacy Attack Evaluation／Membership Inference／Inversion／Extraction学習済みAIモデルは、通常の推論APIとして提供されていても、学習データへの参加有無を推定するmembership inference、学習データの属性・代表情報を推定するmodel inversion/reconstruction、target modelの機能や知的財産を複製するmodel extraction/model theftの対象になり得る。これらは目的・必要アクセス・成功指標が異なるため、同じ「情報漏えい」として一括評価
• EA · EA-1212Mistral Platform／Open-weight Operating Profile「Mistralの運用条件はprovider名ではなく、surface・model/version・weight artifact・license・runtime・region/data-processing条件を分離して確認する。」 「open-weightであること、APIで提供されること、同じmodel family名であることを、同一の契約・runtime・data boundaryの証拠として扱わない。」
• EA · EA-227E-signature APIをAI/Agent文書業務へ接続する際の送信・署名状態・権限・証跡境界「AIが署名文書を生成・API送信できること」と「正しい当事者が意図した文書へ有効に署名し、必要な証跡が保存されたこと」は別です。不可逆な送信前に文書version/hash、recipient、environment、権限、承認を固定し、送信response、署名状態、最終文書を別々にreadbackします。test mode、webhook受信、access removalを、それぞれ法的成立、exactly-once処理、全消去の
• EA · EA-249ETL・ELTからAIの知識索引まで更新の成立を追うETLは取り出したデータを変換してから読み込み、ELTは読み込んだ後の基盤で変換します。AIの知識更新では、その後にも解析、分割、embedding、索引公開、権限の反映があります。取込ジョブが成功しただけで、検索や回答が最新・正確・閲覧可能になったとは判断できません。原本から検索可能な版まで、何がどこまで反映されたかを追います。
• EA · EA-250AIが使うデータの契約とスキーマ変更を管理するデータ契約は、作る側と使う側が、項目、型、意味、品質、更新、権限、変更手順を共有する約束です。AIが入力をそれらしく解釈しても、契約違反が直ったことにはなりません。項目名や型の互換性と、金額・時刻・対象集団等の意味の互換性を分け、変更の影響を検索、prompt、tool、評価データまで追います。
• EA · EA-251Data Quality Gate for RAG／AIRAG/AIのData Quality Gateは、定義したdata constraintsを満たさないrevisionをindex/servingへ進めないための制御です。 Gate PASSは「検査したconstraintを満たした」ことを示します。retrieval relevance、groundedness、answer correctnessまで保証するものではありません。
• EA · EA-252Data Lineage／ProvenanceをAI回答までつなぐAI回答のcitation、execution trace、data lineageは同一ではありません。 citationは回答からsourceを参照する表示、traceはLLM・retrieval・tool等の実行経路、lineageはsource artifactから派生artifactまでのderivationです。監査・再現・影響分析に使う場合は、この三者をstable identifierで接続します。
• EA · EA-253Data Catalog／Metadata Catalog × AIData CatalogをAI/Agentのcontext sourceにする場合、検索結果をそのまま正本データや実行権限として扱いません。 Catalogから取得したcontextには、可能な範囲でentity identity、source locator、metadata revision/freshness、owner、glossary/term、lineage、quality、authorization境界を残します。
• EA · EA-254Event Schema Registry × AgentEvent Schema RegistryはAgentのevent contract gateとして有効ですが、`compatibility PASS`をbusiness semantics、全consumerのruntime成功、publish権限、Agent action安全性の保証として扱いません。
• EA · EA-256KMS／HSM／Envelope Encryption for AIKMS/HSMはAI workloadのroot/key material保護と監査可能なcryptographic gateに有効です。ただし、KMS/HSMを利用しているだけでprompt、application memory、DEK cache、logs、vector data、tool actionまで自動的に安全になるとは扱いません。
• EA · EA-257Confidential Computing／TEE × AIConfidential Computing／TEEは、定義したthreat modelの範囲でAI workloadのdata-in-useと実行環境をhost/operatorから隔離し、remote attestationをsecret/key releaseの条件にできます。 ただし、TEEやattestation PASSだけでapplication code、GPU、side channel、availability、pro
• EA · EA-260API ManagementをAgent Tool層に置くAgentからtool APIへ到達する経路にAPI Management/API Gatewayを置くと、認証、公開route/tool、rate/quota、protocol/schema、監査を集中しやすくなります。
• EA · EA-277Data Masking／Tokenization before LLM「LLM前のmasking/tokenizationは機微データ露出を減らすcontrolであり、匿名化や漏えい防止の保証ではありません。必要データだけを送り、検出漏れ、tokenのlinkability、再識別鍵・mapping、quasi-identifier、ログ／cache、出力側を別々に管理します。可逆tokenの復元はLLMから分離した認可済み境界で行います。」
• EA · EA-279Consent／Purpose Limitation × AI Data Use「AIで個人データを使えるかは、同意の有無だけでは決まらない。目的、処理段階、法的根拠、再利用互換性、通知、権利処理を法域と実装境界ごとに確認し、承認済みpurposeをruntimeのdata-flow gateへ投影する。UNKNOWNを同意済み・互換ありと推測しない。」
• EA · EA-281Tenant Isolation for Multi-tenant AI「認証由来のテナント文脈を全データ・操作経路へ渡し、保存先と実行主体の認可を強制して分離する」。一方、「テナントIDをプロンプトに書けば分離済み」「索引を分ければ全経路が安全」「専用GPUなら会話やログも分離済み」とはしない。
• EA · EA-282Row／Column-level Security × AI Analytics「実行主体とデータ基盤のポリシーで取得可能な行・列を制限し、AI入力と下流出力にも同じ権限を保つ」。一方、「プロンプトに権限を書けば十分」「RLSがあれば列も匿名化される」「結果0件ならフィルタを外す」「DB設定済みなので出力全体も安全」とはしない。
• EA · EA-513派生AIデータの消去と埋め込み・索引の残留管理原文を削除しても、その原文から作ったチャンク、埋め込み、索引、要約、評価用コピーまで消えたとは限りません。派生AIデータの消去では、元データとの依存関係、削除操作が及ぶ単位、検索からの不可視化、保存領域の回収、バックアップからの再導入、再生成を別々に管理します。EA-512が削除要求全体の伝播と証拠を扱うのに対し、本項は派生表現と保存層の残留を扱います。
• EA · EA-514AIメモリの訂正伝播と古い派生データの修復AIメモリの訂正では、元データの変更成功と、そのデータに依存する要約、ベクトル、索引、キャッシュ、検索結果の更新完了を分けます。正本が訂正済みでも、古い派生物が同じシステムに残り、回答へ再利用されることがあります。依存関係と版を管理し、影響する派生物を再計算し、提供経路で修復結果を再読込することが必要です。本項は訂正と収束を扱い、削除要求の伝播はEA-512、物理的な埋め込み残留はEA-513に接続します。
• EA · EA-515共有AIメモリのテナント分離共有AIメモリでは、利用者・チーム・顧客の識別子を保存するだけでは分離が成立しません。認証された主体から許可する範囲を決定し、読取、書込、更新、削除、要約、検索、キャッシュ、復元まで同じ範囲を適用する必要があります。検索だけにフィルタを付けても、別の経路で他テナントの記憶が更新・合成されれば分離は破れます。本項は共有メモリの権限伝播と運用検証を扱い、削除はEA-512、訂正収束はEA-514に接続します。
• EA · EA-517情報区分に応じたAIメモリの保持期限とTTLAIメモリの保持は、すべての記憶へ同じTTLを付けるだけでは管理できません。情報区分、利用目的、元データの版、保持の根拠、起算点、派生物、保持例外を対応させ、期限到達、提供停止、削除指示、実削除、backupの失効を分けて確認します。TTLは製品の削除・失効機構であり、組織が定める保持要件全体と同じものではありません。
• EA · EA-518コンテキストの出所ラベルと指示・データの境界コンテキストには、現在の指示、利用者の入力、検索文書、toolの結果、過去の記憶、agentが作った要約など、異なる出所と役割の情報が混在します。出所ラベルはそれらを区別して追跡するために使います。ただし、本文中に「信頼済み」「system」「正本」と書いてあることは権限の証明ではありません。出所、生成・変換の履歴、現在の権限、鮮度、実際のprompt配置を分け、重要な操作の許可を参照データの記述だけから決定しない必要があります。
• EA · EA-521Cross-provider Schema Loss Accounting Envelope「Structured Outputsを使えばJSON Schemaどおりになる」「三providerで同じschemaを使える」とは表現しない。安全な表現は、「各providerのdocumented subsetと実効strictnessをversion付きで確認し、canonical schemaからprovider schemaへの変換差分を記録し、生成後にcanonical constraintを再検証する。表現不能な重要co
• EA · EA-735本番トレースを評価データセットへ戻すフィードバックループ「本番traceは評価データセットの有力な入力であり、versioned datasetへ昇格して回帰評価へ戻せる。ただし代表性、PII、redaction、version混在、rare-event欠落をcontrolし、trace-derived setだけを完全な品質保証とみなさない。」
• EA · EA-745Privacy-preserving synthetic evaluation data「synthetic dataなので個人情報を含まず安全」とは表現しません。安全な表現は、「synthetic evaluation dataは元データの直接配布を減らせるが、privacyは自動的には保証されない。utility、memorization/re-identification risk、DP等のformal guaranteeを分離して評価し、用途に応じたprivacy/utility gateを設ける」です。
• EA · EA-758multimodal media cacheのUUID衝突・tenant隔離evidence_as_of: 2026-10-27 JST
• EA · PM-CLAUDE-CORE-07CLAUDE：評価データと公開前の評価契約CORE-07のdataset、scorer/judge、holdout、slice gate、release evidenceを、Anthropicの評価設計guidance、Console prompt improver/evaluator、Message Batches、structured outputs、Agent SDK/Claude Codeおよびauthor-maintained cookbookへ対応づける。公開仕様・
• EA · PM-GPT-CORE-07OpenAI / GPT：評価データと公開前の評価契約CORE-07のgolden dataset、holdout、scorer/judge registry、slice-level AND gate、release/rollback evidenceをOpenAIのDatasets、Evals、Graders、Agent evals、Prompt optimizerおよびopenai/evals OSSへ対応づける。公開仕様と固定OSSだけを対象とし、実tenant、非公開dataset
• EA · PM-GROK-CORE-07GROK：評価データと公開前の評価契約CORE-07のgolden dataset、scorer/judge、holdout、slice/tail gate、release evidenceを、Grok 4.6 announcement/model card、xAI APIのBatch/structured-output/model identity、author-maintained Grok Build、独立benchmark methodologyへ対応づける。公開b
• EA · PROVENANCE_POLICY出典の来歴と根拠の扱い本辞典は、チャット本文、S001〜S063、packet、registerを、それだけで外部知識の原典とは扱わない。これらは編纂容器・研究記録・中間成果物になり得る。外部情報を含むclaimは、容器を越えて原著者・原組織・原資料まで遡れることを公開条件とする。