# cyber-secure.tech — Full Content Bundle for LLMs
# This file aggregates the full plain-text content of public insight articles.
# Generated at build time from Astro Content Collections.
# For a link summary, see https://cyber-secure.tech/llms.txt
---
URL: https://cyber-secure.tech/insights/dynamic-mas-governance-principles-2026-05-17
Title: 証跡駆動・自己改善型Dynamic MASとAIクローン 第二回——AIエージェントを「動かす」から「統制する」へ
Last-Modified: 2026-05-17

本シリーズでは、証跡駆動・自己改善型のDynamic MASとAIクローンに関する設計と運用の記録を、SPA-IT（Security × Privacy × AI Governance）視点から段階的に整理している。

第一回では、なぜチャットボットでも固定ワークフローでもなくDynamic MASなのか、なぜ証跡駆動なのかという思想的背景を扱った。

本稿（第二回）では、その続編として、AIエージェントを単に動かすのではなく、説明可能で統制可能な状態に置くための設計原則を整理する。

なお、本稿では再現可能な内部実装の詳細ではなく、ガバナンス上の論点と設計判断の考え方に焦点を置く。実装証跡・具体構成は第三回以降で、必要な証跡と説明責任を伴う形で扱う。

---

なぜ「チャットボット」でも「固定ワークフロー」でもないのか

チャットボットの限界

チャットボットはリクエストに応答するが、タスクを管理しない。会話が終わればコンテキストが消え、「先週の判断」を翌週のセッションが引き継ぐ仕組みがない。進捗・証跡・承認記録が残らない。

固定ワークフロー自動化の限界

RPA・固定シーケンス型の自動化は、予め定義した手順を機械的に実行する。しかし現実のタスクは、状況に応じてルートが変わり、複数の観点から検討すべき場面があり、人間の判断が必要な境界が存在する。固定手順はその柔軟性を持てない。

Dynamic MASが解く問題

Dynamic MAS（動的マルチエージェントシステム）は、タスクの性質に応じてエージェントが動的に選択・派遣され、合議し、証跡を残しながら進行する。変化する状況への適応性と、ガバナンス的な説明責任を両立する設計が求められる。

---

設計の核心：4つの原則

本稿では、これらを4つの設計原則として整理する。これは筆者の実装経験を通じた整理であり、重要なのは、それらを自律的なAIエージェント基盤の中で一体として扱う点である。

1. MCP-first（標準ツールバス）

主要な操作を標準化されたプロトコルインターフェース経由に寄せる。タスク作成・証跡添付・合議・通知・承認といった重要操作を、可能な限り同一のインターフェース上で扱う。個別のCLIを直接呼び出す場合もフォールバックとして許容されるが、その場合も監査ログへの記録を義務付ける。

標準バスを選択した理由は単純だ。監査性。全呼び出しを監査記録として残せば、「誰が何を使っていつ実行したか」が一意に追跡できる。セキュリティ視点ではアタックサーフェスの局所化、ガバナンス視点では監査ポイントの一元化だ。

2. RDB-backed（構造化された永続ストアをSoTとして使う）

AIの記憶は揺れる。セッションが変われば解釈がずれる。この問題を根本から解決するには、状態管理をAIの外に出すしかない。

構造化された永続ストア（リレーショナルDB）を唯一の真実のソース（Source of Truth）として使い、タスクの状態遷移、全証跡、全ルール、全承認記録をDB上で永続化する。AIが忘れてもDBが覚えている。

このアーキテクチャ選択の核心は、AIの確率的な動作に対して、DBの決定論的な制約が整合性を保証するという点にある。状態管理をAIに任せないという原則だ。

3. Evidence-driven（証跡義務化）

タスクが完了したとしてAIが申告しても、証跡がなければシステムは完了と認めない。完了宣言は証跡の添付を構造的に必要とする設計になっている。これにより、AIの自己申告による完了宣言を防ぐ。

証跡が存在しない完了は、ガバナンス上存在しないも同然だ。ISO/IEC 42001が求める説明責任の実装として、これが最も根拠ある設計だと判断している。

なお、証跡を厚く残せば説明責任は高まるが、同時にPrivacyやdata minimisationとの緊張も生まれる。何を残すか、なぜ残すか、どの目的で再利用するかを設計しなければ、証跡そのものが新たなリスクになる。この点は、Security、Privacy、AI Governanceを分けて考えると見落としやすい。証跡駆動のMASでは、証跡を「多く残す」ことではなく、「目的に照らして説明可能な形で残す」ことが重要になる。詳細は今後のPrivacy編で扱う。

4. Self-improving（失敗も資産化）

定期的な外部情報取り込み、小規模な改善実験、継続失敗時のエスカレーション設計を組み合わせ、失敗・ブロックを改善候補として資産化する。

システムは自分の問題状態（中途停止状態のまま進まないタスク、証跡が接続されていないタスク等）を検出し、修正タスクを生成する。ただし、コアポリシーの変更・重大なアーキテクチャ変更・外部サービスへの影響は、自己改善の対象外であり、必ず人間の判断を経る。

---

HITL境界の設計

AIを使う上で最も重要な問いのひとつは「どこで人間が判断するか」だ。全自動化は危険であり、全人間判断は自動化の意味をなさない。

このシステムでは、たとえば外部公開、永続データ構造に影響する変更、認証情報に関わる操作、本番環境に影響する変更などを、人間の承認を必要とする領域として扱う。これはHITL境界の一例であり、すべてを網羅するものではない。実際のエスカレーション条件はリスクに応じて設計しており、その詳細は第五回で扱う。

---

ガバナンス観点からの位置付け

ISO/IEC 42001（AI Management System）、NIST AI RMF、NCCoEのAIエージェントID管理に関する議論等が重視する要素——説明責任・証跡・HITL・リスクティア管理——を、システム設計の中に組み込むことを重視している。

AIガバナンスを「後から文書化する作業」ではなく「システムの構造として組み込む設計」として捉えることが、実運用型AIエージェント基盤の要件だと考えている。

---

おわりに

「AIを動かす」ことは今や難しくない。難しいのは「AIが何をしたかを後から説明すること」と「AIの判断境界を設計すること」だ。

MCP-first / RDB-backed / Evidence-driven / Self-improving——この4原則は、その難しさに答えるための設計思想である。自律性と統制可能性は、設計によって両立できる。

---

次回（第三回：実装証跡編）では、外部入力からタスク化、エージェント処理、人間判断、証跡化までの一連の流れを、公開可能な範囲の証跡・画面例とともに示す予定です。

---

本稿は、筆者のDynamic MAS環境を用いた生成・レビュー・証跡化プロセスを経たうえで、人間が最終確認したものです。外部公開にあたり、認証情報・内部パス・未実装主張・再現可能性が高すぎる具体的設計情報が含まれていないかを確認しています。

---
URL: https://cyber-secure.tech/en/insights/dynamic-mas-governance-principles-2026-05-17
Title: Evidence-Driven, Self-Improving Dynamic MAS and AI Clones, Part 2: From Running AI Agents to Governing Them
Last-Modified: 2026-05-17

This series documents the design and operation of an evidence-driven, self-improving Dynamic MAS and AI clone environment from the SPA-IT perspective: Security, Privacy, and AI Governance as an integrated discipline.

Part 1 covered the conceptual background: why this is neither a chatbot nor a fixed workflow, and why evidence-driven operation matters.

This second article continues that discussion by organizing the design principles required to place AI agents in an explainable and governable operating state, rather than merely making them run.

This article focuses on governance issues and design judgments, not on implementation details that would make the system directly reproducible. Concrete implementation evidence and architecture details will be addressed in later parts only where they can be shown with appropriate evidence and accountability.

---

Why This Is Neither a Chatbot Nor a Fixed Workflow

The Limits of Chatbots

A chatbot responds to requests, but it does not manage tasks. Once the conversation ends, the context disappears. There is no structural mechanism for next week's session to inherit last week's judgment. Progress, evidence, and approval records do not persist by default.

The Limits of Fixed Workflow Automation

RPA and fixed-sequence automation execute predefined procedures mechanically. Real work, however, changes route depending on context. It often requires examination from multiple perspectives and includes boundaries where human judgment is necessary. Fixed procedures do not have that flexibility.

What Dynamic MAS Solves

A Dynamic MAS, or dynamic multi-agent system, selects and dispatches agents according to the nature of the task, enables them to deliberate, and leaves evidence as work progresses. The design challenge is to combine adaptability to changing conditions with governance-level accountability.

---

The Core Design: Four Principles

I organize the design into four principles. This is a synthesis from my implementation experience. The important point is that these principles must be treated as an integrated part of an autonomous AI agent foundation.

1. MCP-first: A Standard Tool Bus

Core operations should be routed through standardized protocol interfaces wherever possible. Task creation, evidence attachment, deliberation, notifications, and approvals should be handled through a common interface. Direct CLI calls can remain as fallbacks, but when they are used, recording them in audit logs should be mandatory.

The reason for choosing a standard bus is simple: auditability. If every call is retained as an audit record, it becomes possible to trace who used what, when, and for what purpose. From a security perspective, this localizes the attack surface. From a governance perspective, it centralizes audit points.

2. RDB-backed: Use a Structured Persistent Store as the Source of Truth

AI memory is unstable. Interpretation shifts across sessions. The only fundamental way to address this is to move state management outside the AI.

A structured persistent store, specifically a relational database, should be used as the Source of Truth for task transitions, evidence, rules, and approval records. Even if the AI forgets, the database remembers.

The core of this architecture is that deterministic database constraints provide consistency against probabilistic AI behavior. The principle is not to leave state management to the AI.

3. Evidence-driven: Evidence as a Structural Requirement

Even if an AI claims that a task is complete, the system should not recognize completion without evidence. A completion declaration should structurally require evidence attachment. This prevents completion from depending on AI self-attestation.

In governance terms, completion without evidence is effectively nonexistent. I consider this the most defensible implementation of the accountability expected by ISO/IEC 42001.

There is, however, a tension between richer evidence and privacy or data minimisation. If the system records more evidence, accountability improves, but the evidence itself can become a new risk unless the design defines what is recorded, why it is recorded, and for what purpose it may be reused. This point is easy to miss when Security, Privacy, and AI Governance are treated separately. In an evidence-driven MAS, the goal is not to record more, but to record in a way that is explainable against purpose. I will address this in more detail in a later privacy-focused part.

4. Self-improving: Turning Failure Into an Asset

The system should combine periodic external information intake, small improvement experiments, and escalation design for repeated failures, so that failures and blocked states become improvement candidates.

The system detects its own problem states, such as tasks that remain stalled or tasks whose evidence is not connected, and generates repair tasks. At the same time, core policy changes, major architecture changes, and externally impactful changes are outside the scope of self-improvement and must go through human judgment.

---

Designing HITL Boundaries

One of the most important questions in AI operation is where human judgment should enter. Full automation is dangerous, while full human judgment defeats the purpose of automation.

In this system, examples of human-approval domains include external publication, changes that affect persistent data structures, operations involving credentials, and changes that affect production environments. This is only one example of HITL boundary design and is not exhaustive. Actual escalation conditions are designed according to risk. I plan to address that in detail in Part 5.

---

Positioning From an AI Governance Perspective

I emphasize embedding the elements prioritized by ISO/IEC 42001, the NIST AI RMF, and discussions around AI agent identity management at NCCoE: accountability, evidence, HITL, and risk-tier management.

AI governance should not be treated as documentation added afterward. For operational AI agent foundations, governance must be designed into the structure of the system itself.

---

Conclusion

Making AI run is no longer difficult. What remains difficult is explaining afterward what the AI did and designing the boundaries around AI judgment.

MCP-first, RDB-backed, evidence-driven, and self-improving: these four principles are a design philosophy for addressing that difficulty. Autonomy and governability can coexist when they are designed together.

---

In Part 3, which will focus on implementation evidence, I plan to show the flow from external input to task creation, agent processing, human judgment, and evidence capture, using evidence and screen examples that can be made public.

---

This article went through a generation, review, and evidence-capture process using my Dynamic MAS environment, followed by final human review. Before publication, it was checked to ensure that it does not include credentials, internal paths, unimplemented claims, or overly reproducible design details.

---
URL: https://cyber-secure.tech/en/insights/spa-it-governed-dynamic-mas-clone-2026-05-09
Title: Evidence-Driven, Self-Improving Dynamic MAS and an AI Clone — A Design Record from the SPA-IT Perspective
Last-Modified: 2026-05-09

Introduction: "AI That Runs" and "AI That Runs in a Controllable State" Are Not the Same Thing

Automating work with AI is no longer particularly difficult. Call an LLM, use the result, and it runs. The real question is whether that "running" state is sustainable.

What I have been building over the past several months is not merely a system that runs, but a system that runs autonomously while remaining in a controllable state. This article documents the design decisions behind that effort and the reasoning for each, through the lens of SPA-IT — Security, Privacy, and AI-governance: Integrated Technology.

1. Why "Dynamic MAS"?

There is a fundamental difference between fixed-workflow automation and a Dynamic Multi-Agent System.

Fixed workflows are powerful when the assumed procedure is working correctly. But the moment a situation changes, an exception occurs, or a premise breaks — they stop, and a human must intervene. They are systems that halt at the edge of what their designer anticipated.

In a Dynamic MAS, the composition of agents, routing, and fallback behavior changes with circumstances. When task priority shifts, the responsible agent shifts. When one route fails, the system switches to another. This situational adaptation is the fundamental reason the architecture can sustain long-running, multi-faceted operations.

In the context of industry standards, this is an implementation of what IEEE P3394 and the NCCoE AI Agent Identity framework describe as "autonomous agent / dynamic spawn / inter-agent communication." But the distance between what is written in papers and frameworks and what actually surfaces when you run the system is significant.

2. Not Trusting AI Memory — The RDB-Backed Design Choice

LLM output is inherently variable. The same prompt produces different responses. Long contexts cause earlier information to fade. This is a characteristic of LLMs, not a defect. The problem is designing a system without accounting for that variability.

My choice was to make PostgreSQL the sole Source of Truth. Task state, approval history, agent execution records, evidence — all of it is written to the RDB. Agents read state from the RDB, act, and write the results back. Database constraints, not AI memory, enforce consistency.

What this delivers is reproducibility and auditability. When the question arises — which agent made which decision at which point yesterday, and which human approved it — the design can answer immediately. This is what I determined to be the most robust implementation of the documentation and accountability requirements in ISO/IEC 42001.

3. Why MCP as the Standard Tool Bus

Model Context Protocol (MCP) standardizes how AI connects to external tools. Compared to calling each tool directly through individual CLIs, an MCP-mediated architecture looks, at first glance, like an extra layer. The reason for choosing the standard bus is this:

In a direct-CLI architecture, the connection method, error handling, and authentication logic differ per tool. Adding a new tool changes the overall design. This is fast in the short term and accumulates maintenance cost and attack surface over time.

With MCP, the connection layer is standardized. Since every call routes through the same path, logging, auditing, and permission checks can be consolidated in one place. In security terms, this is attack surface localization. In governance terms, it is centralization of audit points. I chose MCP to preserve consistency at extension time.

4. Evidence-Driven Governance — Making the Audit Trail Part of the Design

The fact that "AI did something" does not exist in governance terms unless it is recorded as evidence.

In this system, every significant action is linked to an evidence_refs record. Which task produced which evidence, which approval is substantiated by which evidence — this chain is the substance of the audit trail. Rather than writing output to log files, structuring it as RDB records makes it mechanically searchable and verifiable after the fact.

This is not about formally satisfying ISO or NIST requirements. It is because a system where you cannot immediately identify which agent processed what, and when, is not functionally operational from a governance standpoint. Evidence design belongs at the center of the architecture, not bolted on afterward.

5. Designing the HITL Boundary — What to Automate and Where to Require Human Judgment

The hardest part of HITL design is defining the boundary. Having humans approve everything is safe but does not scale. Full automation is fast, but eventually produces a situation where the system is running exactly as specified — in a direction you did not intend.

My boundary design references the eight escalation triggers proposed in the NCCoE concept paper on AI agent identity: transmission of data to a new destination, writes to a production environment, access to personal information, threshold exceedance, self-modification of plans, consecutive exceptions, spawning of child agents, and departure from defined scope. Any of these triggers requires human approval.

Conversely, low-stakes, reversible tasks that do not trigger any of these conditions proceed automatically. This explicit boundary is what makes autonomy and controllability coexist.

6. The Self-Improvement Loop — A System That Detects Its Own Problems

Any system that keeps running will degrade over time. Tasks accumulate, evidence gaps appear, rules drift from reality. Having a human monitor this continuously is not realistic.

This system includes a mechanism that monitors its own state and detects problem conditions. Tasks that are stuck mid-execution (partial), tasks rendered unexecutable because a dependency changed (frozen), actions without associated evidence — these conditions are detected and repair tasks are generated. Additionally, changes in AI technology, MCP specifications, and LLM security are ingested daily, scored for relevance, and prioritized.

The boundary of self-improvement is also explicitly defined. Changes to core policy, major architectural changes, anything that affects external services, changes to rules governing human HITL decisions — these are outside the scope of self-improvement and always require human judgment.

7. The AI Clone Direction

One of the long-term directions this system is working toward is an AI clone — not merely automating tasks, but reproducing my own judgment axes, thinking patterns, and priorities in an AI.

This is less a technical challenge than a governance one. When an AI designed to act on your behalf makes a decision, where does accountability lie? How much judgment can legitimately be delegated? Without embedding those answers into the design, a clone AI becomes a "useful but uncontrollable proxy."

From the SPA-IT perspective, the AI clone is the domain where HITL density and evidence density must be highest. Every time the clone acts, it creates evidence. Every time it makes a judgment, it passes through a human approval gate. That is my current design position.

Conclusion: "Designed Trust" Versus "Ungrounded Trust"

Many organizations that use AI place implicit trust in a state they describe as "it seems to be working." No errors means it is running. Logs exist means it is auditable. But "running" and "running as intended" are different propositions.

Evidence chains, HITL boundaries, and self-improvement loops are all mechanisms for converting AI system trust from "implicit" to "grounded by design." Not to satisfy standards requirements, but to ensure that humans can continuously understand what is actually happening.

The faster AI operates, the more visible the difference between a system where trust is designed and one where it is not — the difference between something you can govern and something that governs you.

This article represents the personal views of the author as of May 2026 and does not reflect the position of any affiliated organization.

---
URL: https://cyber-secure.tech/insights/spa-it-governed-dynamic-mas-clone-2026-05-09
Title: 証跡駆動・自己改善型Dynamic MASとAIクローン 第一回——SPA-IT視点からの設計記録
Last-Modified: 2026-05-09

本稿は「証跡駆動・自己改善型Dynamic MASとAIクローン」シリーズの第一回（思想編）です。本シリーズでは、SPA-IT（Security × Privacy × AI Governance）視点から、証跡駆動・自己改善型のDynamic MASとAIクローンに関する設計と運用の記録を段階的に整理します。

はじめに：「AIが動く」と「AIが制御可能な状態で動く」は別のことです

AIを使って作業を自動化するのは、今やさほど難しくありません。LLMを呼び出し、結果を使えばそれで動きます。問題は、その「動く」状態が持続可能かどうかです。

私はここ数ヶ月、単に動くAIシステムを作るのではなく、制御可能な状態で自律的に動き続けるシステムを設計・構築してきました。本稿ではその設計上の判断とその根拠を、AIガバナンス・セキュリティ・プライバシーを統合したSPA-IT（Security, Privacy, and AI-governance: Integrated Technology）の視点から整理します。

1. なぜ「Dynamic MAS」なのか

固定ワークフローの自動化と、Dynamic Multi-Agent System（動的マルチエージェントシステム）には根本的な違いがあります。

固定ワークフローは、想定された手順が正しく機能している間は強力です。しかし、状況が変わる・例外が起きる・前提が崩れるという場面になると、人間の介入なしには先へ進めなくなります。設計者が想定した範囲の外に出た瞬間に止まるシステムです。

Dynamic MASは、エージェントの構成・経路・フォールバックが状況に応じて変化します。タスクの優先度が変われば担当エージェントが変わる。あるルートが失敗すれば別のルートへ切り替わる。この「状況適応」が、長期稼働・複合タスクに耐えられる本質的な理由です。

業界標準の文脈では、これはIEEE P3394やNCCoE AI Agent Identity等が想定している「autonomous agent / dynamic spawn / inter-agent communication」の実装です。しかし、論文やフレームワーク文書に書かれていることと、実際に動かしたときに現れる問題の間には、かなりの距離があります。

2. AIの記憶に頼らない設計——RDB-backedという選択

LLMの出力は揺れます。同じプロンプトを送っても返答は変わりうる。コンテキストが長くなれば前半の情報が薄まる。これはLLMの特性であり、欠陥ではありません。問題は、この揺れを前提とせずにシステム設計をすることです。

私が採用したのは、RDB / 構造化された永続ストアを唯一の真実のソース（Source of Truth）とする設計です。タスクの状態、承認履歴、エージェントの実行記録、証跡——これら全てをRDBに書き込む。AIはRDBの状態を読んで行動し、行動した結果をRDBに書き戻す。AIの記憶ではなく、データベースの制約が整合性を保証します。

これにより得られるのは「再現性」と「監査可能性」です。昨日のどの時点でどのエージェントが何を決定し、どの人間が承認したか——これが後から問われたとき、即座に答えられる設計になっています。ISO/IEC 42001が求める文書化・説明責任の実装として、これが最も堅牢だと判断しました。

3. MCPを標準ツールバスとして使う理由

Model Context Protocol（MCP）は、AIと外部ツールの接続を標準化するプロトコルです。各ツールを個別のCLIで直接呼び出す構成と比べると、MCP経由の構成は一見迂回路に見えます。なぜ標準バスを選んだのか。

個別CLI直叩きの構成では、接続方法・エラー処理・認証ロジックがツールごとに異なります。新しいツールを追加するたびに全体の設計が変わる。これは短期的には速いが、長期的にはメンテナンスコストと脆弱性を蓄積します。

MCP経由では、接続レイヤーが標準化される。全ての呼び出しが同一の経路を通るため、ログ・監査・権限チェックを一箇所に集約できます。セキュリティの観点では、これはアタックサーフェスの局所化です。ガバナンスの観点では、監査ポイントの一元化です。拡張時の一貫性を保つためにMCPを選びました。

4. Evidence-driven governance——証跡を設計の一部にする

「AIが何かをした」という事実は、証跡として記録されなければガバナンス上存在しないも同然です。

このシステムでは、重要な作業はすべて証跡レコードに接続されます。どのタスクがどの証跡を生んだか、どの承認がどの証跡によって裏付けられているか——この連鎖が監査証跡の実体です。単にログファイルに出力するのではなく、RDB上のレコードとして構造化することで、後から機械的に検索・検証できます。

これはISOやNISTの要求を「形式的に満たす」ためではありません。実際のインシデント対応で、どのエージェントがいつ何を処理したかを即座に特定できないシステムは、ガバナンス上実質的に機能していないからです。証跡設計は後付けではなく、設計の核心に置くべきものです。

5. HITLの境界設計——自動化していい領域と人間が介入すべき領域

HITL（Human-in-the-Loop）の設計で最も難しいのは、境界の定義です。全部人間が承認すれば安全だが、スケールしない。全部自動化すれば速いが、ある日意図しない方向に正確に動いているという状況になる。

私が実装した境界設計は、米国NCCoEのコンセプトペーパーで提唱されている8つのエスカレーショントリガーを参照しています。外部へのデータ送信、本番環境への書き込み、個人情報へのアクセス、閾値超過、自己計画の変更、連続例外、子エージェントの生成、スコープ逸脱——これらを検知した場合は必ず人間の承認を要求します。

逆に言えば、これらのトリガーに該当しない軽微で可逆的なタスクはエージェントが自動で進める。この「明示的な境界」があってはじめて、自律性とコントローラビリティは両立します。

6. 自己改善ループ——システムが自分の問題を検出する

稼働し続けるシステムは必ず経年劣化します。タスクが積み上がり、証跡が欠け、ルールが現実と乖離し始める。これを人間が定期的に監視するのは現実的ではありません。

このシステムには、自分の状態を監視して問題を検出する仕組みがあります。タスクの状態が中途停止状態のまま止まっている、依存関係が変わって実行不能状態になっている、証跡が接続されていない——こういった問題状態を検出し、修正タスクを生成する。さらに、AI技術・MCP仕様・LLMセキュリティに関する外部変化を定期的に取り込み、改善候補として整理・優先度付けする仕組みも含まれています。

ただし、自己改善の境界も明示的に設けています。コアポリシーの変更・重大なアーキテクチャ変更・外部サービスへの影響・人間のHITL判断に影響するルールの変更——これらは自己改善の対象外であり、必ず人間の判断を経ます。

7. AIクローンという方向性

このシステムが目指している長期的な方向性の一つが、AIクローンです。単に作業を自動化するのではなく、私自身の判断軸・思考パターン・優先順位をAIに再現させるという実験です。

これは技術的な課題というより、ガバナンス上の課題です。「自分の判断を代行するAI」が何かを決定したとき、その責任はどこにあるか。どこまでの判断を委ねてよいか。これを設計として組み込まなければ、クローンAIは「便利だが制御不能な代理人」になります。

SPA-IT視点では、クローンAIの設計はHITLとevidenceの密度が最も高くなる領域です。クローンが行動するたびに証跡を残し、クローンが判断を下すたびに人間の承認ゲートを通る——これが現時点での私の設計方針です。

おわりに：「設計された信頼」と「無根拠な信頼」

AIを使っている組織の多くは、「とりあえず動いている」という状態に対して暗黙的な信頼を置いています。エラーが出なければ動いていると判断する。ログが存在すれば監査可能だと思う。しかし「動いていること」と「意図通りに動いていること」は別の命題です。

証跡駆動・HITL境界・自己改善ループ——これらは全て、AIシステムへの信頼を「暗黙」から「設計された根拠」に変換するための仕組みです。規格要求を満たすためではなく、実際に何が起きているかを人間が把握し続けるための設計です。

AIが高速に動くほど、この「設計された信頼」の有無が、統制できるシステムと統制できないシステムの差として現れます。

本記事は2026年5月時点の情報に基づいた筆者個人の見解であり、所属組織・関係組織の見解ではありません。

---

次回（第二回：統制原則編）では、AIエージェントを単に動かすのではなく、説明可能で統制可能な状態に置くための設計原則を整理します。

---
URL: https://cyber-secure.tech/insights/dynamic-mas-personal-ai-team-2026-05-06
Title: はじめに：AIチームを自前で持つということ
Last-Modified: 2026-05-06

はじめに：AIチームを自前で持つということ

AI Agentが「使えるツール」から「一緒に働く存在」へ変わりつつある、というのは比喩ではありません。

私はここ数ヶ月、マルチエージェントシステム（MAS）を自前で設計・構築し、実業務で動かしてきました。複数のAIエージェントを「チーム」として機能させるだけでなく、自分自身の思考パターンや判断軸を再現するクローンAIを育てるという実験も並行して進めています。AI利用者であると同時に、AIガバナンス・セキュリティ・プライバシーの専門家として、規定や法令を読むだけでなく実際に手を動かし現場で確かめることに意味があるという信念が、この取り組みの出発点です。

本稿では、なぜマルチエージェントなのか、そしてそれを動かすうえで何を設計しなければならないのかを、実務家の視点から整理します。

1. なぜ1つのAIでは足りないのか

1つのAIに何でも聞くというスタイルの限界は、使い込むとすぐに見えてきます。

同じモデルが生成し、同じモデルが確認する——これは構造的に「自己申告」です。誤りがあっても、そのモデルの出力バイアスの範囲内でしか気づけません。人間の組織でも、同一の利害関係者が設計と監査を兼ねることは認められません。AIでも同じ論理が成立します。

マルチエージェントの本質は、この「チェックの独立性」にあります。あるエージェントが生成したアウトプットを、別の観点を持つエージェントが検証し、さらに別のエージェントが論理の一貫性を確認する。この多段階の相互牽制が、1つのAIには出せない出力の信頼性をもたらします。

NIST AI RMFやISO/IEC 42001が「AIの出力に対する適切な人間の監督」を求めているのも、本質的には同じ問題意識です。ただし、人間が全出力を監督するのはスケールしない。その解として、別のモデルのAIエージェントが相互に監督し合う構造が有効になります。

2. 「自律させる」か「制御する」か——HITLの設計

AIを自律的に動かすことと、人間が制御を保つことはトレードオフではありません。設計次第で両立します。

私が実装してきたのは、リスクの高さに応じてゲートを置く仕組みです。軽微で可逆的なタスクはエージェントが自動で進める。外部に影響するものや、不可逆な判断を伴うものは必ず人間の承認を経る。このゲートを「コストのかかる障害物」ではなく「設計された判断点」として機能させることが、実運用での核心です。

ただ、実際に動かしてみると、AIの処理速度が速すぎるためにHITLの「レベル感」が変わることを実感します。人間が介入を想定している場面で、すでにエージェントが次の工程を走り切っているというギャップです。「全部承認なし」で動かすいわゆるYOLOモードの実態と理想の乖離は、論文やフレームワークを読むだけでは体感できません。自分自身で動かして確かめたかった理由の一つがここにあります。

この問題意識から、私は2026年3月、米国NIST National Cybersecurity Center of Excellence（NCCoE）が公募した「AIエージェントのアイデンティティと認証」に関するコンセプトペーパー（NCCoE Concept Paper on AI Agent Identity and Authorization）へパブリックコメントを提出しました。エージェントが動的に別のエージェントを生成・指示する場合の権限の連鎖や、親子関係のスコープ制限をどう設計するかという論点は、HITLの設計とも直結します。

3. 監査可能性をゼロから設計する

「AIが何をしたか」を後から追跡できるか——これがガバナンスの実務上の核心です。

クラウドLLMを使った場合、入力と出力の記録はベンダー側に残ります。自分の管理下にはありません。私がローカルLLMをベースにシステムを設計してきた理由の1つは、ここです。エージェントが何を受け取り、何を推論し、何を実行したか——そのすべてを自前のログとして保持することで、第三者が検証できる監査証跡が生まれます。

これはISO/IEC 42001が求める「AIシステムの文書化と説明責任」の文脈に直接対応します。ただし規格の要求を満たすだけでなく、実際のインシデント時に「誰が何を判断したか」を即座に特定できる設計にしないと運用では使い物になりません。

セキュリティ・プライバシー・AIガバナンスを統合した視点——私がSPA-IT（Security, Privacy, and AI-governance: Integrated Technology）と呼ぶフレームワーク——から見ると、ここは3つの領域が完全に交差する場所です。この交差点を設計の起点にすることで、技術的な実装とガバナンス上の説明責任が、はじめて一つの設計として成立します。

4. 動かして初めて見えるもの

規定や法令を読むことと、実際に動かすことの間には、かなりの距離があります。

エージェント間でデータを渡す際にスキーマが崩れる。ログの形式がUIの期待する構造と噛み合わない。あるエージェントが別のエージェントの出力の誤りを検出したとき、どう引き継ぐか。これらは設計書には書けない、運用して初めて現れる問題です。

もう一つ、見えてくるのは「AIの限界の形」です。1つのエージェントが出力したものを別のエージェントが批判し、さらに別のエージェントが論理を確認する——という工程を繰り返すと、どこで出力が安定し、どこで揺れ続けるかが可視化されます。これは単体のAIを使っているだけでは気づきにくい情報です。また、複数のエージェントの意見が平行線をたどり合議が成立しない場合もあります。そのときは最終的に人間が判断することになる——エージェントが自律的に動くほど、人間の判断が入る場面の「質」が問われるようになるということでもあります。

「AIを使える」と「AIを統制できる」は別の能力です。両方を持った人間が設計に関わることで、組織は「止まらない使い方」ができるようになる。これは実務家としての私の最も根本的な確信です。

おわりに：設計する側に立つこと

1人のチームでAIを自律的に動かすことは、すでに技術的に現実になっています。

問われているのは、それをどう設計するかです。誰が承認し、何を記録し、どこで人間が介入するか。その構造を持たないまま自律性を高めると、ある日システムが「意図していない方向に正確に走っている」という状況に直面します。

設計する側に立つのか、設計された結果を使う側になるのか。その分岐は、AIの能力曲線が急峻になるほど、より早く、より大きな差になって現れると考えています。

本記事は2026年5月時点の情報に基づいた筆者個人の見解であり、所属組織・関係組織の見解ではありません。

---
URL: https://cyber-secure.tech/en/insights/dynamic-mas-personal-ai-team-2026-05-06
Title: Introduction: What It Means to Run Your Own AI Team
Last-Modified: 2026-05-06

Introduction: What It Means to Run Your Own AI Team

Saying that AI agents have shifted from being "useful tools" to "entities you work alongside" is not a metaphor.

Over the past several months, I have been designing, building, and running a multi-agent system (MAS) in real professional work. Beyond making multiple AI agents function as a team, I am running a parallel experiment: building an AI that reproduces my own thinking patterns and judgment — a personal clone. As both an AI practitioner and a specialist in AI governance, security, and privacy, I hold a firm belief that reading frameworks and regulations is not the same as understanding them. You have to build it yourself to know where it actually breaks.

This article examines why multi-agent matters, and what must be designed to make it run safely — from the perspective of a practitioner who has built one.

1. Why One AI Is Not Enough

The limitations of relying on a single AI for everything become visible with sustained use.

When the same model generates an output and the same model validates it, that is, structurally, self-attestation. Any errors will only be detectable within the bias envelope of that model's own outputs. In human organizations, having the same stakeholder design and audit a system is not permitted. The same logic applies to AI.

The core value of a multi-agent architecture lies in the independence of checks. An output generated by one agent is reviewed from a different perspective by a second agent, and its logical consistency is verified by a third. This multi-layered mutual scrutiny produces a level of output reliability that no single AI can match.

NIST AI RMF and ISO/IEC 42001 both call for "appropriate human oversight of AI outputs" — and they do so for exactly this reason. But having humans review every output does not scale. A well-structured multi-agent system, where agents from different models oversee each other, is one practical answer.

2. Autonomy vs. Control — The HITL Design Problem

Running AI autonomously and keeping humans in control are not a tradeoff. With the right design, both are achievable.

What I have implemented is a gate-based structure calibrated to risk. Low-stakes, reversible tasks proceed automatically. Tasks that affect external parties or involve irreversible decisions require human approval first. Making that gate a "designed decision point" rather than a "costly friction" is the operational core of the whole system.

In practice, though, AI processing speed changes the feel of HITL in ways that frameworks do not prepare you for. The system has already moved to the next step before the human intervention point arrives. The gap between the ideal of human oversight and the reality of so-called YOLO mode — where everything runs without approval — is something I wanted to verify for myself, not just read about.

This concern led me to submit a public comment in March 2026 to the U.S. NIST National Cybersecurity Center of Excellence (NCCoE) on its NCCoE Concept Paper on AI Agent Identity and Authorization. The question of how to govern the chain of permissions when one agent dynamically spawns and instructs another — and how to constrain child agent scope relative to the parent — connects directly to the HITL design problem.

3. Designing Auditability From the Ground Up

Can you reconstruct what the AI did, and why, after the fact? This is the operational core of AI governance.

When using cloud LLMs, the record of inputs and outputs sits with the vendor — not in your own custody. One of the reasons I have designed my systems primarily around locally-run LLMs is exactly this. When every agent's inputs, inferences, and actions are retained in logs under your own control, you have an audit trail that a third party can verify.

This maps directly to the documentation and accountability requirements in ISO/IEC 42001. But compliance with the standard alone is not enough — in a real incident, you need to be able to identify who decided what, and when, within seconds. The design has to support that.

From the integrated perspective I call SPA-IT (Security, Privacy, and AI-governance: Integrated Technology), this is the point where all three domains intersect completely. When you treat this intersection as the starting point of your design — rather than bolting governance on afterward — technical implementation and accountability obligations become a single coherent design rather than two separate concerns.

4. What Only Becomes Visible When You Run It

There is a significant gap between reading regulations and frameworks and actually operating a system.

Schema mismatches between agents. Log formats that don't align with what the UI expects. Defining how one agent handles a case where another agent has flagged an error — none of this appears in a design document. It surfaces in operation.

Something else becomes visible too: the shape of AI's limitations. When one agent's output is critiqued by a second, then verified for logical consistency by a third, you can see — quantifiably — where outputs stabilize and where they continue to vary. This is information that a single-AI workflow cannot surface. And when multiple agents reach a deadlock — when consensus fails — the human must decide. The more autonomously agents operate, the more the quality of those human decision points matters.

"Being able to use AI" and "being able to govern AI" are different capabilities. When someone who holds both is involved in the design, an organization can run AI without stopping.

Conclusion: Choosing to Design, or Being Designed For

Running AI autonomously as a one-person team is already technically achievable.

The question is how you design it. Who approves what. What gets logged. Where does the human intervene. Without that structure, increasing autonomy will eventually produce a situation where the system is running exactly as specified — in a direction you did not intend.

The choice between standing on the design side and being on the receiving end of someone else's design will produce increasingly visible differences as AI capability curves continue to steepen.

This article represents the personal views of the author as of May 2026 and does not reflect the position of any affiliated organization.

---
URL: https://cyber-secure.tech/insights/ai-role-reallocation-reality-2026-04-12
Title: はじめに：2ヶ月前の問いは、すでに現実になった
Last-Modified: 2026-04-12

はじめに：2ヶ月前の問いは、すでに現実になった

2月に公開した記事「『AIが仕事を奪う』論争は的外れ」で、次のように書きました。

起きているのは仕事の奪い合いが本質ではなく、役割の再定義と再配置になります。

AIの内部は複雑なパラメータ空間で構成されており、作った本人ですら結果に至る内部の挙動を完全には読めません。

あれから2ヶ月。技術と法制度の両面で、このことを裏付ける具体的な動きが相次ぎました。本稿では、2026年3月末から4月にかけて起きた3つの出来事を取り上げ、「役割の再配置」が抽象的な予測ではなく、今まさに進行中の事象であることを振り返り確認したいと思います。

1. Mythos： 「制御の限界」が国家レベルで顕在化

2026年4月7日、Anthropic社は「Claude Mythos Preview」を限定的に公開しました。

注目すべきは、このモデルの公開が一般向けではなく、Amazon、Apple、Microsoft、CrowdStrikeなど12のパートナー組織による防御的サイバーセキュリティ用途（Project Glasswing）に限定されたという点です。理由は、モデルの能力が高すぎるためです。Mythosは数週間のうちに数千件の未公表脆弱性（いわゆるゼロデイ）を発見し、その中には重大なものも多数含まれていたとされています。見つかった脆弱性の中には10年から20年前から存在していたものもあると報じられています。

開発元であるAnthropicの社内文書が事前にリークされ、その中でMythosは同社のこれまでのモデルを大幅に上回る性能を持ち、悪意ある利用者がバグの発見と悪用に転用した場合のサイバーセキュリティリスクについても言及されていたと報じられています。

2月の記事で書いた「制御の限界」は、まさにこの形で表面化しました。

AIの能力が人間のセキュリティ研究者の発見速度を桁違いに上回ったとき、それは同時に攻撃側にも同じ能力が渡り得ることを意味します。Mythosの限定公開という判断自体が、「この技術をどう管理するか」という役割の再配置の問いそのものです。セキュリティ研究者の仕事がなくなったのではありません。AIが脆弱性を発見し、人間がその修正と判断を担う形に変わった。役割が再配置されたといえそうです。

2. 改正個人情報保護法： データの境界線を引き直す

2026年4月7日、政府は個人情報保護法の改正案を閣議決定しました。

この改正は、AI時代のデータ利活用と個人の保護の両面に同時に手を入れるものです。

これはSPA-ITの考え方、つまりセキュリティとプライバシーとAIガバナンスは分けて考えるのではなく統合的に考える必要があるという私が掲げたフレームワークの考えに近いと思います。

まず緩和の方向では、統計情報等の作成にのみ利用される場合について、個人データの第三者提供や公開されている要配慮個人情報の取得において、一定の条件のもとで本人同意を不要とする整理が行われました。個人情報保護委員会は、この「統計情報等の作成」にはAI開発等も含まれると説明しています。ただし、これはAI開発一般が広く同意不要になるという意味ではなく、統計作成等として整理できる範囲に条件付きで例外を認めるものです。

一方で強化の方向として、違反企業への課徴金制度が新たに導入されます。また、16歳未満の個人情報について法定代理人への同意取得や通知の明文化が行われ、子供のデータに関する規律が強化されました。

この「緩和と強化の同時進行」は、まさに境界線の引き直しです。

人間のデータをAIにどこまで渡してよいのか。その線を、法が具体的に引き始めたということです。2月の記事で述べた「何をAIに任せ、何を人間が担うか。その境界をどう引くか」という問いが、データの取扱いという最も根本的なレベルで、制度として形になり始めたと言えそうです。

3. 経産省「民事責任の手引き」： 「誰の責任か」に法が答え始めた

2026年4月9日、経済産業省は「AI利活用における民事責任の解釈適用に関する手引き」を公表しました。

AIを用いたサービスやシステムが事故に寄与した場合の民事責任について、現行法がどのように解釈適用され得るかの方向性を示したものです。

この手引きでは、配送ルート最適化AI、弁護士業務支援AI、取引審査AI、外観検査AI、自律走行ロボット（AMR）などの想定事例を検討し、AIが利用される形態に応じて「補助／支援型AI」と「依拠／代替型AI」の2類型を整理しています。さらに、補論としてAIエージェントを利用した場合の民事責任についても触れています。

2月の記事の結論は「誰が何に責任を持つかの設計が問われる」でした。

この手引きは、その問いに対して、現行法の解釈という形で具体的に答え始めたものです。AIの出力に基づいて人間が判断する場合と、AIの判断に依拠して業務が遂行される場合とでは、責任の所在が異なる。その整理が、想定事例とともに提示されました。

もちろん、手引きの中でもAIエージェントの扱いは「要検討」の部分が多く残されています。しかし、こうした論点が政府の公式文書において整理され始めたこと自体が、役割の再配置が制度レベルで進行していることの証左です。

おわりに：設計する側に立つか、設計された結果を受け取るか

2月に書いた「役割の再配置」は、2ヶ月で3つの方向から目に見える形で動き始めました。

Mythosは、AIの能力が人間の監督能力を超え始めたことで、技術の管理そのものに新たな役割分担が必要になることを示しました。改正個人情報保護法は、人間のデータとAIの間の境界線を、法が具体的に引き直し始めたことを示しました。そして経産省の民事責任の手引きは、AIと人間の間で責任をどう配分するかという問いに、法的解釈の形で応え始めました。

これらはいずれも、技術を使うかどうかではなく、技術と人間の役割をどう設計するかの問いです。

この設計に参加する側に立つのか、あるいは設計された結果を受け取る側になるのか。その分岐点に、私たちは今いると考えています。

---
URL: https://cyber-secure.tech/en/insights/ai-role-reallocation-reality-2026-04-12
Title: Role Reallocation Becomes Reality: Technology and Regulation Move Together
Last-Modified: 2026-04-12

Introduction: The Question from Two Months Ago Has Already Become Reality

In the article published in February — "The 'Will AI Take Our Jobs' Debate Is Missing the Point" — I wrote: what is happening is not fundamentally a contest over jobs, but a redefinition and reallocation of roles. AI's internals are composed of complex parameter spaces, and even their creators cannot fully read the internal behavior that leads to results.

Two months later, concrete developments on both the technology and regulatory fronts have corroborated this view. This article examines three events from late March to April 2026, confirming that "role reallocation" is not an abstract prediction but a phenomenon actively in progress.

1. Mythos: "The Limits of Control" Materialize at the National Level

On April 7, 2026, Anthropic released "Claude Mythos Preview" on a limited basis. Notably, this release was not public but restricted to defensive cybersecurity use (Project Glasswing) by 12 partner organizations including Amazon, Apple, Microsoft, and CrowdStrike.

The reason: the model's capabilities were too powerful. Mythos reportedly discovered thousands of undisclosed vulnerabilities (so-called zero-days) within weeks, many of them critical. Some vulnerabilities found had existed for 10 to 20 years.

Internal Anthropic documents were leaked beforehand, reportedly stating that Mythos significantly outperformed the company's previous models and noting cybersecurity risks if malicious users repurposed it for bug discovery and exploitation.

The "limits of control" I described in February materialized in precisely this form. When AI's capabilities surpass human security researchers' discovery speed by orders of magnitude, it simultaneously means the same capability could reach the offensive side. The very decision to release Mythos on a limited basis is itself a question of role reallocation — "how do we manage this technology?"

Security researchers' jobs haven't disappeared. Rather, AI discovers vulnerabilities while humans handle remediation and judgment. Roles have been reallocated.

2. Amended Personal Information Protection Act: Redrawing Data Boundaries

On April 7, 2026, the government approved cabinet amendments to the Personal Information Protection Act. This reform simultaneously addresses both data utilization in the AI era and individual protection.

This aligns with the SPA-IT philosophy — that security, privacy, and AI governance must be considered in an integrated manner rather than separately.

On the relaxation side, for cases where personal data is used solely for creating statistical information, third-party provision and acquisition of publicly available sensitive personal information was organized to not require individual consent under certain conditions. The Personal Information Protection Commission explained that "creation of statistical information" includes AI development. However, this does not mean AI development broadly becomes consent-free — it conditionally permits exceptions within the scope classifiable as statistical creation.

On the strengthening side, a surcharge system for violating companies is newly introduced. Additionally, for personal information of individuals under 16, requirements for obtaining consent from legal representatives and notification were codified, strengthening data discipline for children.

This "simultaneous relaxation and strengthening" is precisely a redrawing of boundaries. How much human data can be given to AI — the law has begun concretely drawing that line.

3. METI "Civil Liability Guidelines": The Law Begins Answering "Whose Responsibility?"

On April 9, 2026, the Ministry of Economy, Trade and Industry published "Guidelines on the Interpretation and Application of Civil Liability in AI Utilization." These indicate how current law may be interpreted and applied when AI-powered services or systems contribute to incidents.

The guidelines examine hypothetical cases including delivery route optimization AI, legal practice support AI, transaction screening AI, visual inspection AI, and autonomous mobile robots (AMR), organizing two categories based on how AI is used: "auxiliary/support AI" and "reliance/substitution AI." A supplementary section also addresses civil liability when AI agents are used.

My February article concluded that "the design of who is responsible for what will be questioned." These guidelines have begun concretely answering that question through legal interpretation. When humans judge based on AI output versus when operations are conducted in reliance on AI judgment — the liability differs. This organization was presented alongside hypothetical cases.

Of course, much regarding AI agent treatment remains "under consideration" within the guidelines. However, the very fact that such issues are being organized in official government documents is evidence that role reallocation is progressing at the institutional level.

Conclusion: Will You Stand on the Design Side, or Receive the Designed Outcome?

The "role reallocation" I described in February has begun moving visibly from three directions in just two months.

Mythos demonstrated that as AI capabilities begin exceeding human supervisory abilities, new role divisions are needed for managing the technology itself. The amended Personal Information Protection Act showed that the law has begun concretely redrawing the boundary between human data and AI. And METI's civil liability guidelines began answering how to allocate responsibility between AI and humans through legal interpretation.

All of these are not questions of whether to use technology, but of how to design the roles between technology and humans. Whether we stand on the side that participates in this design, or become the side that receives the designed outcome — we believe we are at that inflection point now.

---
URL: https://cyber-secure.tech/en/insights/multi-llm-consensus-design-2026-03-08
Title: Multi-LLM Consensus Design for Enterprise AI Governance
Last-Modified: 2026-03-08

Introduction: The Inefficiency of "Asking Multiple AIs" Is a Failure of Design

A growing number of business professionals now use ChatGPT, Claude, and Gemini selectively in their work — because each of them responds with different characteristics.

The problem is that this "selective use" has degenerated into a manual back-and-forth. Copy, paste, read across, switch to another window. This is not intellectual work; it is the absence of a process.

1. Design Structure Matters More Than Implementation Means

When you set out to leverage multi-LLM, you have multiple implementation choices.

Direct API calls, multi-agent infrastructure built on LangGraph, parallel queries with diff extraction on a local Dify, or operations through each service's interface. As I touched on in a previous article, I have experience with all of these configurations and understand their respective design challenges.

But what I want to discuss in this article is not the selection of an implementation means. What is far more important in practice is the question that remains common across whichever means you choose: "By what structure should the outputs of multiple AIs be integrated and used in judgment?"

"Technically possible" and "the optimal design" are different questions. The essence is not in the cleverness of the means, but in the design of the judgment structure.

2. Implementation: A Three-Layer Structure of Refiner → Broadcast → Integrator

The AI Broadcaster I built operates with the following three-layer structure.

You start by entering, roughly, what you want to ask.

Layer One: Refiner. Reshapes the input query into "the form each AI is most able to process." It generates a prompt tailored to each selected AI (when multiple are selected, it produces them individually and then integrates them into a final prompt for output).

Layer Two: Broadcast. Based on the reshaped prompts, it submits the same question to each selected AI and retrieves their answers.

Layer Three: Integrator. Integrates the responses from each AI. The design is to surface points of agreement and divergence across the responses and then generate a final integrated view. The AI in charge of integration is also selectable. For demonstration purposes here, three AIs were each made to perform integration.

By placing the responses side by side and identifying where they agree and where they diverge, you can reinforce perspectives that no single AI would have surfaced alone — and each integrator presents what it considers the best final answer.

Ultimately, you end up with multiple integrated results in hand, and it is simply a matter of examining which to adopt, or where the models agree and where they diverge, and making a judgment accordingly.

3. The Design Question That Took the Most Time

What consumed the most time was not technical implementation but design philosophy: "How much should the system decide, and where should human judgment take over?"

In the initial design, I tried to unify the processing approach across Refiners. However, through experimentation, I found that preserving the individuality of each AI's Refiner output improved both the diversity and quality of the final answers. A structure that shared only the objective of "optimizing the prompt" while leaving the approach to each AI's judgment proved effective.

This is structurally identical to organizational decision-making design. If all members are forced into the same thinking framework, diversity is lost and the quality of collective intelligence declines. The same phenomenon occurs in AI consensus design.

4. Governance Implications of Multi-LLM Consensus

Dependency on a single model carries the same risk structure as designing a single point of failure. Diversity of judgment, cross-verification, and transparency of the integration process — these are fundamental requirements in reliability engineering, and the same holds true in the context of AI governance.

To implement the "appropriate understanding and management of AI outputs" required by ISO/IEC 42001 and the NIST AI RMF at the implementation level, a structure is needed that can trace which model made which judgment and on what basis. Multi-LLM consensus design can be one approach that naturally guarantees this structure.

Furthermore, consensus-based approaches can be expected to reduce hallucination risk and mitigate bias. The quality of AI decision-making is not determined solely by the performance of individual models — it changes through the design of the consensus process. This is a systems design problem, and simultaneously a governance problem.

This article represents the personal views of the author based on information available as of March 2026, and does not represent the views of any affiliated or related organization.

---
URL: https://cyber-secure.tech/insights/multi-llm-consensus-design-2026-03-08
Title: はじめに：「複数のAIに聞く」という行為の非効率は、設計の欠如だ
Last-Modified: 2026-03-08

はじめに：「複数のAIに聞く」という行為の非効率は、設計の欠如だ

ChatGPT、Claude、Geminiを業務で使い分けているビジネスパーソンは増えました。
それぞれの応答特性が異なるからです。
問題は、この「使い分け」が手動の往復作業になっている点にあります。コピーして、貼り付けて、読み比べて、また別のウィンドウへ。これは知的作業ではなく、プロセスの欠如です。

1. 実装手段よりも設計構造

マルチLLMの活用を考えるとき、実装手段の選択肢は複数あります。

API直接呼び出し、LangGraphを用いたマルチエージェント基盤、ローカルDifyでの並列クエリと差分抽出、あるいは各サービスのインターフェースを通じた運用。前稿で触れた通り、これらの構成はいずれも経験しており、それぞれの設計上の課題も把握しています。

しかし本稿で論じたいのは実装手段の選定ではありません。どの手段を使うにしても共通して残る問い「複数のAIの出力をどういう構造で統合し、判断に使うか」の方が、実務的にはるかに重要です。

「技術的にできる」と「それが最適な設計か」は別の問いです。手段の巧みさではなく、判断構造の設計にこそ本質があります。

2. 実装：Refiner → Broadcast → Integrator の三層構造

開発したAI Broadcasterは、以下の三層構造で動作します。

最初に聞きたいことをざっくり入れます。

第一層：Refiner入力クエリを「そのAIが最も処理しやすい形式」に整形します。選択した各AIに合わせたプロンプトを生成します（複数選択時は個別に作成後、統合して最終プロンプトを出力します）。

第二層：Broadcast　整形されたプロンプトを元に、選択した各AIに対して同じ質問を投入し、回答を取得します。

第三層：Integrator各AIの回答を統合します。回答の共通点や差分を踏まえたうえで、最終的な統合見解を生成する設計です。統合を担当するAIも選択可能です。ここではデモ用に3つのAIに統合を行わせました。

各回答を並べ、どこが一致しどこが分かれているか、複数AIに聞くことで単一AIでは見つけられなかった観点の補強、そして最終的に最善と考える回答をそれぞれが提示します。

最終的には複数の統合結果が手元に残りますので、どれを採用するか、あるいはどこが一致していてどこが割れているかを見ながら判断するだけです。

3. 設計で最も時間がかかった問い

実装の技術的な問題より、設計思想の問題に時間を要しました。

「どこまでをシステム側が決め、どこからを人間の判断に委ねるか」という問いです。

最初の設計ではRefinerの処理方針を統一しようとしました。しかし試行の結果、各AIのRefiner出力に個性を残した方が、最終的な回答の多様性と質が上がることがわかりました。「プロンプトを最良化する」という目的だけを共通化し、アプローチはAIの判断に委ねる構造が機能しました。

これは組織の意思決定設計と同型の問題です。メンバー全員に同一の思考フレームを強制すると多様性が失われ、集合知の質が下がります。AIの合議設計でも同じことが起きます。

4. マルチLLM合議が示すガバナンスの含意

単一モデルへの依存は、単一障害点の設計と同じリスク構造を持ちます。判断の多様性、相互検証、統合プロセスの透明性——これらはシステムの信頼性設計における基本要件であり、AIガバナンスの文脈でも同様です。

ISO/IEC 42001やNIST AI RMFが求める「AIの出力に対する適切な理解と管理」を実装レベルで実現するには、どのモデルがどの判断を行い、その根拠はどこにあるかを追跡できる構造が必要です。複数LLMの合議設計は、その構造を自然に担保する一つのアプローチになりえます。

また、合議によってハルシネーションリスクの低下やバイアスの軽減も見込まれます。

AIの意思決定品質は、個々のモデルの性能だけでは決まりません。合議の設計によって変わります。これはシステム設計の問題であり、同時にガバナンスの問題でもあります。

本記事は2026年3月時点の情報に基づいた筆者個人の見解であり、所属組織・関係組織の見解ではありません。

---
URL: https://cyber-secure.tech/insights/ai-role-reallocation-technology-shift-2026-02-23
Title: はじめに：その問いの立て方自体は正しいのか
Last-Modified: 2026-02-23

はじめに：その問いの立て方自体は正しいのか

「AIに仕事を奪われる」という言い方が定着して久しいです。

メディアで出てくる専門家は「この仕事は奪われる」などの論争を繰り返し、企業は対策を急ぎ、現場は不安を抱えます。

しかし私はこの問いの立て方自体に、ずっと違和感を持ち続けています。

奪う・奪わないという二項対立は、今起きていることの本質を捉えきれていないと考えるからです。

1.「手段が変わった時代」と「思考や行為が変わる時代」は、何が違うのか

わかりやすくするために1990年代以降のIT技術の変遷を一本の軸で整理してみます。

インターネットは、物理的な距離に依存した通信を瞬時の電子的な通信に置き換えました。

スマートフォンは、限られた場所にあったコンピューターを全員の手の中に届けました。

クラウドは、自前で用意し所有していたコンピュータを、必要に応じて借りる形に変えました。

いずれも大きな変化です。

ただ共通しているのは、「手段が変わった」という点です。

速く・広く・効率的にはなったのですが、変わっていない部分があります。例えば、判断、設計、責任などでこれらは当然人間の役割でした。

AIはここが根本的に違います。

生成AIは、自律的な側面を持ちながら一定の判断結果を出力し、それに基づいて調査して設計案を出し、コード等を生成します。
ロボティクスでは運転、搬送、その他人間が行なっていた作業を自動的に行います。
AIエージェントは目標を与えられると、ツールやシステムを自律的に操作しながらプロセス全体を実行します。
これらは「手段の高速化／効率化」ではなく、「人間がやっていた思考から行為まで」が機械に移り始めた変化といえます。

2. なぜAIだけが「質的に異なる転換」なのか

行為が機械に移るという変化は、産業革命にも先例があります。

もちろん似通った部分や濃淡で一概に言えない部分もありますが、一体AIは何が大きく違うのか。

決定的な差は、「制御の限界」が同時に生じている点です。

AIの内部は複雑なパラメータ空間で構成されており、作った本人ですら結果に至る内部の挙動を完全には読めません。

従来のルールベースシステムのように「仕様＝挙動」として制御することができないのです。

もちろん一定の結果等の評価はできますが、完全に制御はできません。

例えば産業革命の機械は、設計通りに動きました。

だからこそ人間は明確に設計者・監督を立てましたが、AIはそう単純ではありません。

知的作業の一部への代替が進みながらも、その挙動を完全には制御できないのです。

この二つが重なることで、従来のITとも、かつての機械化とも異なる問題が生まれます。

3.「奪う・奪わない」ではなく、人とAIの役割が再配置される

この視点から「仕事を奪う論争」を見直すと、問い自体のズレが見えてきます。

人間の感覚・経験・文脈判断に根ざした領域は残りますが、責任を引き受けるのもその境界を設計するのも依然として人間です。

AIがなかった時代に人間がやっていたことの一部がAIに移ることで、人間がやるべきこと・やれることの定義が書き換わります。

これは企業レベルでも社会レベルでも、人・予算・役割の配置が再編されますし個人レベルでも起こり得ます。

こうして考えてみると、起きているのは仕事の奪い合いが本質ではなく、役割の再定義と再配置になります。

ただしこれは、自動的に起きるわけではありませんし、何をAIに任せ、何を人間が担うか。誰が監督し、誰が責任を引き受けるか。その境界をどう引くか。

これらの適切な設計がなければ、再配置ではなく混乱や喪失になりえます。

おわりに：技術の設計と同じくらい、「役割の設計」が問われる時代へ

AIはこれまでの道具の進化とは異なります。

人間と機械（コンピュータ）のあいだで、役割の再配置が起きているのです。

だからこそ、技術をどう使うかと同じくらい（あるいはそれ以上に）「誰が何に責任を持つか」の設計が問われます。

その問いから逃げたまま導入を進めることが、企業にとっても社会にとっても最大のリスクになりえる時代に、私たちはいます。

---
URL: https://cyber-secure.tech/en/insights/ai-role-reallocation-technology-shift-2026-02-23
Title: AI Role Reallocation: The 'Will AI Take Our Jobs' Debate Is Missing the Point
Last-Modified: 2026-02-23

Introduction: Is the Question Itself Properly Framed?

The phrase "AI will take our jobs" has become well-established. Media experts repeat debates about which jobs will be displaced, companies rush to prepare countermeasures, and workers carry anxiety. Yet I have long felt uncomfortable with the framing of this question itself — because the binary of "take or not take" fails to capture the essence of what is actually happening.

1. What Distinguishes "When Tools Change" from "When Thinking and Action Change"?

To illustrate, let us trace the evolution of IT since the 1990s along a single axis:
- The internet replaced distance-dependent physical communication with instantaneous electronic communication.
- Smartphones placed computers — previously confined to specific locations — into everyone's hands.
- Cloud computing changed owned, self-provisioned computers into on-demand rentals.

All were significant changes. But what they share in common is that the tools changed. Things became faster, broader, more efficient — yet certain things remained unchanged: judgment, design, responsibility. These remained firmly human roles.

AI is fundamentally different. Generative AI produces judgment outputs with a degree of autonomy, conducts research, proposes designs, and generates code. Robotics automates driving, transport, and other tasks humans previously performed. AI agents, given goals, autonomously operate tools and systems to execute entire processes.

This is not "acceleration or efficiency of tools" — it is the beginning of a shift where "what humans used to think and do" begins transferring to machines.

2. Why AI Alone Represents a "Qualitatively Different Transformation"

The shift of action to machines has precedent in the Industrial Revolution. But what fundamentally distinguishes AI?

The decisive difference is that "the limits of control" emerge simultaneously. AI's internals are composed of complex parameter spaces, and even their creators cannot fully read the internal behavior that leads to results. Unlike traditional rule-based systems where "specification equals behavior," complete control is impossible.

The Industrial Revolution's machines operated as designed — humans could clearly position themselves as designers and supervisors. AI is not so simple. Even as it substitutes for portions of intellectual work, its behavior cannot be fully controlled. When these two factors overlap, problems arise that differ from both conventional IT and historical mechanization.

3. Not "Take or Not Take" — Roles Between Humans and AI Are Being Reallocated

Viewed from this perspective, the flaw in the "job displacement debate" becomes clear.

Domains rooted in human sensation, experience, and contextual judgment remain — and accepting responsibility and designing those boundaries are still human roles. As portions of what humans did in the pre-AI era shift to AI, the definition of what humans should and can do is being rewritten.

This reallocation of people, budgets, and roles occurs at the enterprise level, the societal level, and even the individual level.

Seen this way, what is happening is not fundamentally a contest over jobs, but a redefinition and reallocation of roles. However, this does not happen automatically. What to delegate to AI, what humans should own, who supervises, who accepts responsibility, and how to draw those boundaries — without proper design, what results is not reallocation but confusion and loss.

Conclusion: An Era Where "Role Design" Matters as Much as Technology Design

AI differs from the evolution of tools that preceded it. A reallocation of roles between humans and machines (computers) is underway. That is precisely why — as much as or more than how to use the technology — the design of "who is responsible for what" is being challenged.

We are in an era where proceeding with adoption while avoiding that question may be the greatest risk for both enterprises and society.

---
URL: https://cyber-secure.tech/insights/ai-agent-governance-design-2026-02-15
Title: はじめに：2026年、AIの「使い方」だけを追いかけていないか
Last-Modified: 2026-02-15

はじめに：2026年、AIの「使い方」だけを追いかけていないか

2026年に入り、AIの主戦場は「エージェント」に移りました。

AIが"答える存在"から、"実行する存在"へ変わりつつあります。象徴的なのは、ファイルやブラウザを自律的に操作してタスクを完了させる機能が、各社から次々に出てきたことです。AnthropicのClaude Cowork、OpenAIのOperator——いずれも「対話」ではなく「実行」を前提にした設計です。

YouTubeやSNSでは「AI Agentの使い方」「プロンプト術」「業務効率化」があふれています。それは有益です。しかし、ガバナンス・セキュリティ・プライバシーの実務に携わる立場から見ると、語られていない領域がかなり大きい。

本記事では、「動かす」だけでなく「安全に使う（統制する）」ために何を考えるべきかを、複数の専門領域を横断する視点から整理します。

1. 「答えるAI」と「実行するAI」は、リスクの構造が根本的に違う

従来の対話型AIは、基本的に「情報を返す」存在でした。誤った情報を返しても、それを判断して行動するのは人間です。

AI Agentは違います。ファイルを読み書きし、APIを叩き、ブラウザを操作し、場合によっては別のAIエージェントに指示を出す。判断と実行が近接している——ここがリスク構造の根本的な転換点です。

攻撃面（Attack Surface）の拡大。 プロンプトインジェクションの影響が「おかしな回答」ではなく「ファイル削除・データ流出」といった実害に近づきます。Webページや文書に埋め込まれた隠し指示がエージェントの行動を乗っ取る——これはすでに実証されている攻撃パターンです。OWASP Top 10 for LLMsではプロンプトインジェクションが最上位に位置づけられていますが、エージェントの文脈ではその影響範囲が「回答の汚染」から「実行の乗っ取り」に拡大します。MITRE ATLASが体系化しているAIシステム固有の攻撃手法——データポイズニング、モデル窃取、推論操作なども、エージェントが外部ツールやAPIと接続する分だけ現実的な脅威になります。

権限（Identity）の問題。 AI Agentは「誰として」行動しているのか。多くの場面で、エージェントは人間ユーザーの権限を借りて動いています。そのエージェントが自律的に別のエージェントを起動したとき、権限の連鎖は追跡可能なのか。ここを設計していない組織は非常に多い。

速度の問題。 人間のオペレーションミスは数時間から数日のスパンで顕在化します。AIエージェントの誤動作は、数分で大量のデータを処理してしまいます。検知して止める時間が、従来の前提では足りません。

2. ガバナンスの議論が追いつきにくい理由

AI Agentは、既存のガバナンス体系の"隙間"に入りやすい存在です。

従来のセキュリティ管理は「人間のユーザー」と「決定論的に動くプログラム」を前提に設計されてきました。

AI Agentは、人間のように判断し、プログラムのように速く動き、しかも非決定的（同じ入力でも出力が揺れる）です。IAM（Identity and Access Management）もGRC（Governance, Risk, Compliance）も、このような「第三の存在」を正面から想定していません。

この問題意識は国際的にも前面化しています。2026年2月に公表された「International AI Safety Report 2026」では、汎用AIの能力とリスク、特にエージェントの自律的動作がもたらすリスクが主要テーマとして整理されています。シンガポールIMDAが「Agentic AI」に関するガバナンス枠組みを2026年1月に公表し、キルスイッチ（強制停止）や目的拘束（purpose binding）といった技術的統制を明示したことも、同じ方向性です。

しかし、フレームワークが出ることと、現場の統制が回ることは別の話です。これはセキュリティだけの問題でも、プライバシーだけの問題でも、AI倫理だけの問題でもありません。複数の領域を横断して俯瞰しなければ、運用設計として成立しない——そういう種類の問題です。

3. 開発者がガバナンス側に来たからこそ分かること

私のキャリアは、もともとソフトウェア開発から始まっています。20年以上、認証基盤や決済システムといったミッションクリティカルな領域でコードを書き、設計し、運用してきました。その後セキュリティ、プライバシー、AIガバナンスへと軸足を移しましたが、移ったからこそ痛感していることがあります。

「作ったことがない人間が書くガバナンスは、現場で回らない」ということです。

これは従来のセキュリティ領域でも同じでした。

開発プロセスを知らない人間がセキュリティポリシーを書くと、現場は形骸化した運用で"やってる風"にするしかなくなる。

逆に、開発の経験があれば「ここに穴が開く」「この設計だと運用で破綻する」が肌感覚で分かるし実際の攻撃も行える。（もちろん法の範囲で）

つまり机上の空論になりがちなケースが多いので、実際作る。と言うのが私のスタイルです。

AI Agentの世界でも、まったく同じ構造が再現されています。だから私は、既製エージェントを評価して使うだけでなく、ローカル環境でマルチエージェントシステムを自分で設計・構築することを続けています。

具体的には、LangGraphを用いたグラフベースのワークフローで、複数のAIノード——生成・批判・統合・保存といった役割を分離したパイプラインを動かしています。

さらにオープンソースLLMにLoRA（Low-Rank Adaptation）を適用し、特定の判断パターンや出力形式を再現する専用モデルを育てています。夜間に自律的に回す設計です。

やってみると、フレームワークの解説書には載っていないことが次々に見えてきます。ノード間の情報の受け渡しでスキーマが崩れる。UIが参照するログ形式とエージェント本体の保存形式が噛み合わない。こうした「泥臭い現実」は、作った人間にしか見えません。

もう一つの論点はデータ主権（Data Sovereignty）と監査可能性です。ローカルで動くエージェントは業務データをクラウドLLMベンダーに送信しません。

入力→推論→出力→実行の全プロセスのログを自分の管理下に保持し、後から第三者が検証できる形で記録できます。クラウドとローカルをリスクと用途に応じてハイブリッドに設計する

——その判断軸は、両方を触った経験からしか出てきません。

4. 「出力」と「判断」を分離する習慣

AI Agentを「放置して回す」こと自体が目的ではありません。目的は、人間の判断を、次の生成に反映できる形で蓄積することです。

私自身がAIの出力を扱う際に重視しているのは、以下の3層への明示的な分解です。
- Facts（事実）：入力データに基づく確認済みの情報
- Inferences（推測）：モデルによる推論。根拠と確度を必ず付記
- Open Questions（未確定論点）：追加の確認や人間の判断が必要な事項
この形式に寄せると、レビュー可能になり、"それっぽい文章"が混入しにくくなります。そして人間のフィードバック——どこが誤りで、どこが妥当か——を次のサイクルに反映しやすくなります。

これはISO/IEC 42001やNIST AI RMFの文脈でも「AIの出力に対する適切な理解と管理」として求められている方向性ですが、実務レベルでどう実装するかは、まだほとんどの組織で設計されていません。

5. 横断しなければ設計できない時代

AI Agent時代の問題は、単一領域の専門家だけでは解けません。

エージェントの権限設計にはIAMの知識が要る。データの流れを追うにはプライバシーエンジニアリングが要る。出力の信頼性を評価するにはAIリスク管理が要る。そしてそもそも、エージェントがどう動いているかを理解するにはコードが読めなければ話にならない。

セキュリティ、プライバシー、AIガバナンス、そして開発。この4つのどれか1つだけでは、現場で回る統制設計にならない。逆に言えば、これらを横断できる人間が「何がどう壊れるか」を見ながら設計を組めれば、組織はAIを止めずに済みます。

自分で作り、壊し、直した経験に基づいて統制を設計する——これが、フレームワークの解説やツールの使い方紹介とは異なる、私のアプローチです。

おわりに：「使えること」と「統制できること」の両立へ

AI Agentは確実に業務の形を変えていきます。止める話ではありません。

ただ「使える」だけを追うと、統制の死角が積み上がります。いま導入しているAI Agentは、誰の権限で動いていて、どのデータにアクセスし、どのログが残り、誰が最終責任を持つのか

——この問いに答えられる構造があるからこそ、AIを安心して加速できます。

革新と安全性はトレードオフではありません。

CYBER-SECUREでは、セキュリティ・プライバシー・AIガバナンスを横断し、「作る側の視点」を持った統合的なコンサルティングを提供しています。AI Agentの導入・統制設計・リスク評価でお困りの際は、お気軽にお問い合わせください。

本記事は2026年2月時点の情報に基づいた筆者個人の見解であり、所属組織・関係組織の見解ではありません。

---
URL: https://cyber-secure.tech/en/insights/ai-agent-governance-design-2026-02-15
Title: AI Agent Governance Design
Last-Modified: 2026-02-15

Introduction: In 2026, Are You Only Chasing "How to Use" AI?

As 2026 begins, the main battleground of AI has shifted to "agents."

AI is moving from being an entity that "answers" to one that "executes." The most symbolic development is the wave of features released by major vendors that let AI autonomously operate files and browsers to complete tasks. Anthropic's Claude Cowork, OpenAI's Operator — both are designed around "execution" rather than "dialogue."

YouTube and social media are flooded with content on "how to use AI agents," "prompt techniques," and "operational efficiency." That is useful. But viewed from the perspective of someone working in governance, security, and privacy, there is a substantial body of issues that simply isn't being discussed.

This article organizes what needs to be considered in order to "use AI safely (i.e., govern it)" — not just "make it run" — from a perspective that crosses multiple specialist domains.

1. "Answering AI" and "Executing AI" Have Fundamentally Different Risk Structures

Traditional conversational AI was, at its core, an entity that "returns information." Even when it returned wrong information, the human was the one who judged it and acted on it.

AI agents are different. They read and write files, hit APIs, operate browsers, and in some cases issue instructions to other AI agents. Judgment and execution have been compressed together — and this is the fundamental inflection point in the risk structure.

Expansion of the attack surface. The impact of prompt injection moves from "an odd answer" closer to real-world harm such as "deleted files" or "data exfiltration." Hidden instructions embedded in web pages or documents that hijack an agent's behavior — this is already a demonstrated attack pattern. The OWASP Top 10 for LLMs places prompt injection at the top, but in the agent context, its blast radius expands from "contamination of the answer" to "hijacking of execution." The AI-system-specific attack techniques systematized in MITRE ATLAS — data poisoning, model theft, inference manipulation — also become realistic threats to the extent that agents connect to external tools and APIs.

The identity (privilege) problem. "As whom" is the AI agent acting? In many situations, an agent operates by borrowing the privileges of its human user. When that agent autonomously launches another agent, is the chain of privileges traceable? A great many organizations have not designed for this.

The speed problem. Human operational mistakes typically surface over hours to days. AI agent malfunctions can process massive volumes of data in minutes. The window of time for detection and intervention is shorter than traditional assumptions allow.

2. Why the Governance Discussion Struggles to Keep Up

AI agents tend to fall into the "gaps" of existing governance frameworks.

Traditional security management has been designed assuming "human users" and "deterministic programs."

AI agents judge like humans, move at the speed of programs, and are non-deterministic on top of it (the same input can produce varying outputs). Neither IAM (Identity and Access Management) nor GRC (Governance, Risk, Compliance) frameworks were built with this "third kind of actor" squarely in mind.

This concern has now surfaced internationally. The "International AI Safety Report 2026," published in February 2026, identifies the capabilities and risks of general-purpose AI — particularly the risks brought by autonomous agent behavior — as a major theme. Singapore's IMDA published a governance framework for "Agentic AI" in January 2026, explicitly requiring technical controls such as kill switches (forced halts) and purpose binding — pointing in the same direction.

But "frameworks being published" and "controls actually working in the field" are different things. This is not solely a security problem, nor solely a privacy problem, nor solely an AI ethics problem. It is the kind of problem that cannot be designed into a working operational structure unless it is viewed across multiple domains at once.

3. What Becomes Visible Only Because a Developer Has Moved into Governance

My career originally began in software development. For more than 20 years, I wrote, designed, and operated code in mission-critical domains such as authentication infrastructure and payment systems. I subsequently shifted my center of gravity toward security, privacy, and AI governance, but the move itself is what made one thing painfully clear:

"Governance written by people who have never built things doesn't work in the field."

The same pattern existed in traditional security. When someone with no understanding of the development process writes a security policy, the field has no choice but to operate as a hollow ritual that "looks like" they're doing the work.

Conversely, with development experience you can sense in your fingertips "where the hole will open" and "where this design will collapse in operation" — and you can actually carry out the attacks (within the bounds of the law).

In other words, because cases of pure desk theory are common, my style is to actually build it.

The same structure plays out completely in the AI agent world. That is why I continue not only to evaluate and use off-the-shelf agents, but to design and build multi-agent systems myself in a local environment.

Specifically, I run pipelines on top of LangGraph using graph-based workflows, with multiple AI nodes — generation, criticism, integration, persistence — separated by role.

I additionally apply LoRA (Low-Rank Adaptation) to open-source LLMs to grow specialized models that reproduce specific judgment patterns or output formats. The design runs autonomously overnight.

When you actually do this, things that aren't in any framework documentation start to surface. Schemas break across information hand-offs between nodes. The log format the UI consumes does not align with the agent's own persistence format. These "gritty realities" are visible only to the people who built it.

Another axis is data sovereignty and auditability. Locally running agents do not transmit business data to cloud LLM vendors. Logs of the entire pipeline — input → inference → output → execution — can be retained under your own control and recorded in a form that lets a third party verify them after the fact. Designing the cloud-and-local split as a hybrid that responds to risk and use case is a judgment axis that only emerges from having touched both sides.

4. The Habit of Separating "Output" from "Judgment"

The point of an AI agent is not "to leave it running and walk away." The point is to accumulate human judgment in a form that can be reflected back into the next round of generation.

When I personally handle AI output, what I emphasize is an explicit decomposition into three layers:
- Facts: Confirmed information based on input data
- Inferences: Inferences made by the model — always with grounds and a confidence level attached
- Open Questions: Items requiring additional verification or human judgment

When you push the format toward this shape, output becomes reviewable, and "plausible-sounding text" has a harder time slipping in. And human feedback — what was wrong, what was sound — becomes easier to feed back into the next cycle.

This is the same direction that ISO/IEC 42001 and NIST AI RMF call for under "appropriate understanding and management of AI output" — but how to implement it at the practical level is something most organizations have not yet designed.

5. The Era When You Can't Design Without Cutting Across Domains

The problems of the AI agent era cannot be solved by single-domain specialists alone.

Privilege design for agents requires IAM knowledge. Tracing data flow requires privacy engineering. Evaluating output reliability requires AI risk management. And to even understand how an agent is moving, you have to be able to read code.

Security, privacy, AI governance, and development. With only one of these four, you do not get a control design that works in the field. Conversely, when someone who can cut across all four watches "what breaks and how" while assembling the design, the organization can avoid having to halt AI.

Designing controls based on the experience of having built it yourself, broken it, and fixed it — this is my approach, and it is distinct from explanations of frameworks or tutorials on how to use a tool.

Conclusion: Toward Reconciling "Being Usable" with "Being Controllable"

AI agents will reshape the form of work — that much is certain. This is not a conversation about stopping them.

But chasing only "usability" causes blind spots in governance to pile up. The AI agent you are introducing right now — under whose authority is it operating, what data does it access, what logs are retained, and who holds final accountability?

Because there is a structure capable of answering these questions, you can accelerate AI safely.

Innovation and safety are not a tradeoff.

CYBER-SECURE provides integrated consulting that crosses security, privacy, and AI governance — informed by the perspective of someone who has been on the building side. If you are facing challenges in introducing, controlling, or risk-assessing AI agents, please feel free to reach out.

This article represents the personal views of the author based on information available as of February 2026, and does not represent the views of any affiliated or related organization.

---
URL: https://cyber-secure.tech/insights/ai-and-human-work-structure-2025-12-30
Title: はじめに：AIのニュースに疲れている人へ
Last-Modified: 2025-12-30

はじめに：AIのニュースに疲れている人へ

最近、AIのニュースを見るたびに、こんな不安がよぎる方が多いと思います。

「この仕事は危ないらしい」

「いや、やっぱり人間が必要らしい」

「結局どっちなんだ」

専門家ですら言っていることが毎週のように変わるので、追いかけるだけで疲れてしまいます。

そこで、私なりの見解として一度整理しておきたいことがあります。

AIの未来について、毎週のニュースで一喜一憂する必要はありません。

もう少し長い目で見て考えるときに大事なのは「新機能」ではなく、変わりにくいものに目を向けることだからです。

まず、はっきり言えることがあります。

「AIができること」は、これからも増え続けます。

・文章を書く

・調べる

・企画のたたき台を作る

・デザイン案を量産する

・プログラムの下書きを書く

・議事録やメールを整える

こうした「作業」や「下準備」は、今後さらにAIが強くなります。

5年後も10年後も、人が時間をかけている作業の多くはAIに移っていくでしょう。

だから、「正確さ」や「スピード」でAIに勝とうとする考え方はおすすめしません。

そこは人間が勝ち続ける場所ではないからです。

すると、よく次のように聞かれます。

「人間の仕事はなくなるのでしょうか？」

いえ、そうではありません。

AIがどれだけ賢くなっても、簡単には変わらないものがあります。

それは能力の問題ではなく、社会の仕組みの問題です。

わかりやすくするために4つに分けて説明します。

1. 「誰が決めたことにするか」を引き受ける役割

AIは答えを出せます。

しかし人間社会では必ず、「この方針でいきます」「これで公開します」「これでリリースします」と決める瞬間があります。

・デザイナーなら：

AIはロゴ案を100パターン出せます。

でも「このブランドにふさわしいのは案Bだ」と決め、クライアントに納品する責任を持つのは人間です。

・エンジニアなら：

AIはコードを書けます。

でも「この変更を本番に出す（デプロイする）」と判断し、ボタンを押すのは人間です。

・編集者なら：

AIは文章を整えられます。

でも「この表現で出していい」「名誉や権利に触れていない」と最終判断するのは人間です。

大事なのは正しさだけではありません。

何かあったとき、「誰の判断だったか」が問われます。

AIに法人格（電子的人格）を認めようという議論も一部にはあります。

しかし、少なくとも主要な規制の設計思想では「AIではなく、それを設計・提供・運用する人間や企業の責任を問う」という方向です。

結局のところ、「誰の名義で動かし、誰が引き受けるか」を決めるのは、最後まで人間側なのです。

2. 人を納得させる役割

人は正しいだけでは動きません。

・不安な人を落ち着かせる

・怒っている人をなだめる

・不利な結果を説明して受け入れてもらう

これは「理屈だけでは割り切れない部分」です。

・営業・接客なら：

スペック説明はAIでもできます。

でも、クレームのお客様の目を見て謝り、納得して帰ってもらうのは人間です。

・UI/UXなら：

正解っぽい導線はAIも作れます。

でも「この変更はユーザーの不安を増やす」「この言葉は誤解を生む」と感じ取り、

反発を抑える言い方で合意を取りに行くのは人間です。

・会計・経理なら：

数字の整理はAIが得意です。

でも「なぜこの支出が必要だったか」を、監査や上長に“通る言葉”で説明するのは人間です。

AIがどれだけ論理的でも、最後に腹落ちを作るのは人間です。

3. 誰が得して、誰が損するかの折り合いをつける役割

AIは「全体として効率の良い案」を出せます。

しかし現実は、効率だけでは決まりません。

・誰を優先するか

・誰に負担をお願いするか

・どこまでを許すか

これは正解探しではなく、折り合い（いろんな人が絡み合う場合の落としどころ）です。

・管理職・経営者なら：

「A事業部は儲かるが、B事業部を縮小すると現場が崩れる」

こういう場面は、数字だけでは決められません。

・プロデューサー／ディレクターなら：

「クオリティを上げたい現場」対「納期を守れという営業」

その板挟みの中で、落とし所を作るのは人間です。

・法務・人事なら：

ルールを厳しくすると現場が止まる。

緩くすると事故が増える。

その折り合いは、最後は人が決めるしかありません。

この調整は、今後も人間の仕事です。

4. 失敗したあとに、社会を立て直す役割

どれだけ優秀なAIであれ、人であれ、「想定外」は起きます。

そのときに必要なのは、後からちゃんと立て直す力です。

・医師なら：

AI支援があっても、予期せぬ事態が起きたときに、家族へ説明し、最善を尽くすのは人間です。

・企業の広報・担当者なら：

炎上が起きたとき、定型文ではなく、誰に向けてどう謝罪し、信頼を取り戻すかは人間です。

・クリエイターなら：

著作権・肖像・炎上の火種が出たとき、

作品を守りつつ、関係者と落ち着いて調整するのは人間です。

これがなければ、安心して次に進めません。

ここは今後も、人間の役割として残ります。

そしてもう1つだけ付け足すなら、

「失敗した後」だけでなく「失敗を減らすための設計（予防策）」を誰がやるか、も重要になっていきます。

つまり、仕事は消えるのではなく、役割がズレていくだけです。

10年後に求められるのは、「AIよりうまく作業できる人」ではなく、「AIが出したものを、人間社会で使える形に整える人」です。

5. 一般の人が明日からできること

難しい勉強や大きな決断は必要ありません。

明日からできることを7つ挙げます。

1. AIの出力をそのまま出さない

AIが作った文章、デザイン案、企画案、コード、説明文。

そのまま流さないでください。

最後に一言だけ添えます。

「私はこう理解しました」

「ここがブランドに合いません」

「この点は確認が必要です」

この一言があるだけで、あなたは「作業者」から「判断者」に寄ります。

2. 一番困る人を先に想像する

「この案で一番困るのは誰か」

「どこで反発が出そうか」

たとえば、主婦なら「家計がきつくなる瞬間」、

学生なら「評価が決まる提出物」、

現場なら「問い合わせが殺到する導線」。

“特定の痛み”を先回りできる人の価値は残ります。

3. 迷ったときのルール（基準）を決めておく

デザイナーなら「トーン＆マナー（らしさ）の基準」。

エンジニアなら「本番に出していい条件」。

事務なら「どの時点で上げるかの基準」。

個別判断より、判断の“型”を作れる人が重宝されます。

4. 小さな例外対応を一つ持つ

「このお客様だけ特別対応が必要」

「この条件だけエラーが出る」

「この表現だけ炎上しやすい」

ちょっと面倒なイレギュラーを一つ引き受ける。

それだけで役割は未来側に寄ります。

5. 言い方（伝え方）を工夫する

事実を並べるのはAIでもできます。

でも「この順番なら角が立たない」「この言葉なら安心する」は人間です。

納得を作る仕事は残ります。

6. 困ったときの連絡先になる

すごい知識はいりません。

「それは誰に聞けばいいか」を知っていて、話を整理してつなげる。

それだけで価値があります。

7. 時間配分を変える

作成や下準備など、AIができる部分はAIに寄せる。

その上で、人が担う部分に意識的に時間を使います。

・確認は人がやる

・調整・説明は人がやる

・例外・後始末も人がやる

この配分を意識するだけで、AIを使いこなす側（置き換わりにくい側）へ寄りやすくなります。

6. 組織で準備すべき3つの仕組み

先ほどまでが「個人でできること」でした。

ここからは、組織でAIを使っていくなら、という観点で整理します。

組織で考える場合は個人の努力だけでは十分ではなく、組織ならではで準備すべきものが3つあります。

（※3つ全部に、セキュリティ／プライバシー／AIガバナンスが絡みます）

1. 名義と責任のルール（誰が引き受けるか）

AIの出力を、誰の判断として扱うのか。

どこまで自動化を認めるのか。

例外時に誰がGOサインを出すのか。

ここが曖昧だと、事故の責任だけでなく、データの扱い・判断の公平性・説明の筋まで全部ブレます。

2. 使い方とデータの境界線（何を入れて、何を残すか）

AIは便利ですが、データの扱い方で一発で詰むことがあります。

そして「境界線」は、セキュリティ／プライバシー／AIガバナンスの三つ巴になりやすい。

たとえば、AIの判断ログをどう扱うか。

セキュリティ部門は「改ざん防止のため長期保管」と言い、

プライバシー部門は「個人データなので短期削除」と言い、

法務は「説明責任のため証拠保全」と言う。

この3つを同時に満たす設計にしないと、後から全部やり直しになります。

3. 事故後の説明と信頼回復の手順（後始末を設計しておく）

誤判定、漏えい、炎上、業務停止。

こういった例外が起きた時に、誰が何を説明し、どこまで補償し、どう再発防止を約束するのか。

ここも三領域が絡みます。

説明のために何を開示するか（セキュリティ）、

誰の権利に触れるか（プライバシー）、

なぜその判断を通したか（ガバナンス）。

後始末の設計がないと、一度の失敗で信頼が壊れます。

7. 最後に

まずは、「AIの答えを流す人」ではなく、「AIの答えを使える形に整える人」になる。

個人でできることは今日から始められます。

一方で、組織としてAIをどう統制するか（名義と責任、データの境界線、事故後の説明設計）は、専門性が交差する領域で、片手間で進めるとだいたい後でやり直しになります。

だから最初から横断的に考えるのが望ましいです。

本記事が、AI時代を必要以上に怖がらずに前へ進むためのヒントになれば幸いです。

---
URL: https://cyber-secure.tech/en/insights/ai-and-human-work-structure-2025-12-30
Title: For Those Tired of AI News: What Won't Change About Human Work
Last-Modified: 2025-12-30

Introduction: For Those Tired of AI News

Lately, every time AI news appears, many people feel a wave of anxiety: "This job is supposedly at risk." "Actually, humans are still needed." "So which is it?"

Even experts seem to change what they say every week, and just keeping up is exhausting.

So I'd like to organize my own perspective once. You don't need to ride an emotional roller coaster with every weekly AI headline. When taking a longer view, what matters is not "new features" but focusing on what is unlikely to change.

First, one thing is clear: what AI can do will continue to expand.
- Writing text
- Researching
- Creating draft proposals
- Mass-producing design concepts
- Writing code drafts
- Polishing meeting notes and emails

These kinds of "tasks" and "preparation work" will increasingly shift to AI. Five years from now, ten years from now, much of the time humans spend on such work will transfer to AI.

That's why I don't recommend trying to beat AI on "accuracy" or "speed." Those aren't arenas where humans will keep winning.

This naturally leads to the question: "Will human jobs disappear?"

No, they won't. No matter how smart AI becomes, there are things that won't easily change. This isn't a matter of capability — it's a matter of how society is structured.

To make this clear, let me explain in four categories.

1. The Role of Taking Ownership of Decisions

AI can produce answers. But in human society, there's always a moment when someone must say: "We're going with this direction," "This is approved for publication," "This is cleared for release."
- For designers: AI can generate 100 logo concepts. But deciding "Option B is right for this brand" and taking responsibility for delivering it to the client — that's human work.
- For engineers: AI can write code. But deciding "this change goes to production" and pressing the deploy button — that's human work.
- For editors: AI can polish text. But making the final call that "this expression is acceptable" and "this doesn't infringe on anyone's reputation or rights" — that's human work.

What matters isn't just correctness. When something goes wrong, the question becomes: "Whose decision was this?"

There are discussions about granting AI legal personhood (electronic personhood). However, at least in the design philosophy of major regulations, the direction is to hold the humans and companies who design, provide, and operate AI responsible — not the AI itself.

Ultimately, deciding "under whose name this operates, and who takes responsibility" remains on the human side.

2. The Role of Getting People on Board

People don't act on logic alone.
- Calming someone who is anxious
- Soothing someone who is angry
- Explaining an unfavorable outcome and gaining acceptance

These are areas where "pure logic doesn't cut it."
- In sales and customer service: AI can handle spec explanations. But looking a complaining customer in the eye, apologizing, and having them leave satisfied — that's human work.
- In UI/UX: AI can create plausible user flows. But sensing that "this change increases user anxiety" or "this wording creates misunderstanding," and then building consensus through carefully chosen language — that's human work.
- In accounting and finance: AI excels at organizing numbers. But explaining "why this expenditure was necessary" to auditors and supervisors in language that passes — that's human work.

No matter how logical AI becomes, creating that final "gut-level understanding" is human work.

3. The Role of Mediating Who Benefits and Who Bears the Cost

AI can propose "the most efficient plan overall." But reality isn't determined by efficiency alone.
- Who gets priority?
- Who is asked to bear the burden?
- Where do we draw the line?

This isn't about finding the right answer — it's about finding a workable compromise among many stakeholders.
- For managers and executives: "Division A is profitable, but downsizing Division B would collapse the frontline operations." These situations can't be decided by numbers alone.
- For producers and directors: "The production team wants higher quality" versus "sales demands the deadline be met." Finding the landing point amid that tension is human work.
- For legal and HR: Tighten the rules and the frontline grinds to a halt. Loosen them and incidents increase. That balance is ultimately something people must decide.

This mediation will remain human work going forward.

4. The Role of Rebuilding Society After Failure

No matter how excellent an AI or person may be, "the unexpected" happens. What's needed then is the ability to rebuild properly afterward.
- For doctors: Even with AI support, when unforeseen situations arise, explaining to family members and doing everything possible — that's human work.
- For corporate PR and representatives: When a crisis erupts, deciding who to address, how to apologize, and how to rebuild trust beyond boilerplate responses — that's human work.
- For creators: When copyright, likeness, or controversy issues emerge, protecting the work while calmly coordinating with stakeholders — that's human work.

Without this, no one can move forward with confidence. This role will remain with humans going forward.

And one more addition: it's not just about "after failure" — who designs the systems to "prevent failure" (preventive measures) will become increasingly important too.

In other words, jobs don't disappear — roles shift.

What will be valued in 10 years is not "people who can perform tasks better than AI," but "people who can take what AI produces and shape it for use in human society."

5. Seven Things Ordinary People Can Start Tomorrow

No difficult study or big decisions required. Here are seven things you can start tomorrow.

1. Don't pass along AI output as-is

AI-generated text, design concepts, proposals, code, explanations — don't just forward them. Add just one line:

"Here's how I understood this." "This doesn't fit our brand." "This point needs verification."

That single line shifts you from "task worker" to "decision maker."

2. Imagine who would be most affected first

"Who would be most troubled by this plan?" "Where would pushback come from?"

For homemakers: "the moment household finances get tight." For students: "the assignment that determines your grade." For frontline workers: "the flow that generates a flood of inquiries."

People who can anticipate specific pain points ahead of time will retain their value.

3. Set rules for when you're unsure

For designers: "tone and manner standards." For engineers: "conditions for deploying to production." For office workers: "criteria for escalating to supervisors."

People who can create "frameworks" for judgment, rather than making individual decisions each time, will be valued.

4. Take on one small exception

"This customer needs special handling." "This condition alone produces errors." "This expression alone tends to cause backlash."

Taking on just one slightly troublesome irregularity shifts your role toward the future side.

5. Craft how you communicate

AI can line up facts. But "this order won't ruffle feathers" or "this wording puts people at ease" — that's human.

Work that creates understanding will endure.

6. Be the person to call when there's trouble

You don't need amazing knowledge. Just knowing "who to ask about that" and being able to organize the conversation and connect people — that alone has value.

7. Shift your time allocation

Delegate creation and preparation — tasks AI can handle — to AI. Then consciously spend time on the parts only humans can do:
- Verification is done by humans
- Coordination and explanation is done by humans
- Exception handling and aftermath is done by humans

Just being conscious of this allocation makes it easier to stay on the side that uses AI (the side that's hard to replace).

6. Three Systems Organizations Should Prepare

Everything above was about what individuals can do. From here, let me organize what organizations need when incorporating AI. For organizations, individual effort alone isn't sufficient — there are three things that must be prepared at the organizational level.

(Note: All three involve security, privacy, and AI governance.)

1. Rules for attribution and responsibility (who takes ownership)

Whose judgment does AI output count as? How much automation is permitted? Who gives the green light in exceptional cases?

If this is ambiguous, not only incident responsibility but also data handling, fairness of decisions, and the logic of explanations — everything becomes inconsistent.

2. Boundaries for usage and data (what goes in, what stays out)

AI is convenient, but one mistake in data handling can be fatal. And these "boundaries" tend to become a three-way contest among security, privacy, and AI governance.

For example, how to handle AI decision logs: Security says "long-term retention to prevent tampering." Privacy says "delete quickly because it's personal data." Legal says "preserve as evidence for accountability."

Without designs that satisfy all three simultaneously, everything has to be redone later.

3. Procedures for post-incident explanation and trust recovery (designing the aftermath)

Misjudgments, data breaches, crises, operational shutdowns. When these exceptions occur, who explains what, how much compensation is provided, and how recurrence prevention is promised?

This too involves all three domains: what to disclose for explanation (security), whose rights are affected (privacy), and why that decision was approved (governance).

Without designed aftermath procedures, a single failure can destroy trust.

7. In Closing

Start by becoming "the person who shapes AI answers for practical use," rather than "the person who just passes along AI answers."

What individuals can do starts today. On the other hand, organizational AI governance — attribution and responsibility, data boundaries, post-incident explanation design — is a domain where multiple specialties intersect, and rushing through it almost always leads to rework.

That's why it's best to think cross-functionally from the beginning. I hope this article serves as a hint for moving forward in the AI era without excessive fear.

Disclaimer: This article represents the personal views of the author based on information available as of December 2025, and does not represent the views of any affiliated or related organization.

---
URL: https://cyber-secure.tech/insights/ai-governance-safety-implementation-2025-12-20
Title: AIガバナンス×プライバシー×セキュリティを横断する実務の視点 — SPA-IT による実装設計
Last-Modified: 2025-12-20

はじめに：AI時代のジレンマとAIガバナンス×プライバシー×セキュリティを横断する実務の視点 - SPA Integrated Trust Triad（SPA-IT）による実装設計 -

生成AIの業務利用が進む一方で、多くの組織が同じジレンマに直面しています。
- ビジネスとしてはAI活用を進めたい
- 現場はスピードと自由度を求めている
- 一方で、人権・プライバシー・安全性は軽視できない
しかし、この原則を 現場で“実装可能な形”に落とし込むこと は、決して簡単ではありません。

本記事では、セキュリティ（Security）、プライバシー（Privacy）、AIガバナンス（AI Governance）を統合し、単一の専門領域に閉じない横断的な実効性を持たせる統合的アプローチ「SPA Integrated Trust Triad（SPA-IT）」の視点から、原則と現実のギャップをどう調整するかを整理します。

1. AI原則は「正しい」が、そのままでは動かない

OECD AI原則は非常に重要です。
- 革新
- 人権の尊重
- 安全性・堅牢性
- 説明責任
どれも否定のしようがありません。

一方で、現場では次の声が上がります。
- 「結局、何をすればいいのか分からない」
- 「全部確認していたら開発が止まる」
- 「どこまでやれば十分なのか判断できない」
原則は目的地を示しますが、道順（設計と運用） までは教えてくれません。

2. セキュリティだけでも、プライバシーだけでも、AIガバナンスだけでも、開発経験だけでも足りない

AI時代の問題は、単一領域の最適化では解けません（セキュリティ／プライバシー／AIガバナンス／開発のどれか一つだけでは足りない）。

現場で機能させるには、組織やユースケースに応じて設計を組み替える必要があります。

例えば一例として、シャドウAIの棚卸 → リスク区分 → 例外設計 → ログ／証跡と責任分界を、開発プロセスの中で回る形に再設計する、という整理が考えられます。

セキュリティ・開発・プライバシー・AIガバナンスを横断して俯瞰し、この「原則と現場のギャップ」を実装可能な統制へ落とし込むことが必要です。

ここで一度、あなたの立場から考えてみてください。専門がどこかによって、現場は概ね次のような状態になりがちです。
- セキュリティ視点だけ → 全部禁止が最適解になりがち
- プライバシー視点だけ → 現場で回らない
- ガバナンス視点だけ → 抽象論で終わる
- 開発視点だけ → リスクが見えない
- 利用者視点だけ→ 便利さ優先でルールは面倒だから回避されがち
必要なのは、それぞれの論理を理解した上で折り合いを付ける設計です。
これは理論ではなく、実務でしか身につかない領域だと感じています。

3. 「使わせない」のではなく「判断できる状態」を作る

実務で機能するAIガバナンスの共通点は、抽象化してみると意外とシンプルです。
- 何がOKで、何がNGか
- どこからが要判断か
- 誰が判断し、誰が責任を持つか
これらが事前に定義されていること。一律禁止でも、現場丸投げでもなく、判断できる余地を残した包括的対策が必要です。

4. 革新と安全性はトレードオフではない

AI活用において、
1. 革新を取るか
1. 安全性・人権を取るか
という二者択一に見える場面があります。

しかし実際には統合的な設計次第で両立は可能です。
- 人が介入すべきポイントを明確にする
- 判断と責任の所在を事前に決める
- ログ（証跡）と説明可能性を確保する
これらは、革新を止めるためではなく安心してアクセルを踏むための前提条件です。

5. 実装可能性を測るためのチェック観点（抜粋）

ここでは「SPA-IT」の視点に基づき、実務で特にボトルネックとなりやすい観点を抽出しています。

なお、ここで述べるのは特定組織の事例ではなく、複数の現場で共通して詰まりやすいポイントを一般化したものです。

多くの組織では、ルール本文よりも「例外の扱い」「証跡」「責任分界」が未整備なまま運用に入り、結果としてシャドウAIが温存されます。

そのため、棚卸と分類の設計、例外運用、ログ／監査の仕組み化までを一続きで設計することが、実装可能性を左右します。
- 入力データの性質は整理されているか
- AIの判断結果が、どこで人間に引き渡されるか
- 想定外の挙動が起きたとき、止める手段はあるか
- 事故時に、説明責任を果たせる状態か
これらは、ツールの種類ではなく「使い方」と「運用」の問題です。

おわりに

AI原則は、
- 人権を守るため
- 活用を進めるため
に存在します。

この両立を現場で実現するには、その原則・技術、そして組織の現実を理解する必要があります。

その視点整理として、AIガバナンス／安全性観点の簡易チェックリスト（Preview版）を公開しています。

AIガバナンス・チェックリスト（Preview）はこちら

免責事項

本検証は2025年12月時点の情報に基づいた筆者個人の見解であり、所属組織・関係組織の見解ではありません。

---
URL: https://cyber-secure.tech/en/insights/ai-governance-safety-implementation-2025-12-20
Title: AI Governance Implementation: The SPA Integrated Trust Triad Approach
Last-Modified: 2025-12-20

Introduction: The Dilemma of the AI Era

As generative AI adoption in business advances, many organizations face the same dilemma:
- The business wants to push forward with AI adoption
- The field demands speed and flexibility

At the same time, human rights, privacy, and safety cannot be neglected. Yet translating these principles into "implementable form" in the field is far from easy.

This article examines how to reconcile the gap between principles and reality from the perspective of the SPA Integrated Trust Triad (SPA-IT) — an integrated approach that unifies Security, Privacy, and AI Governance with cross-domain practical effectiveness.

1. AI Principles Are "Correct" — But They Don't Move on Their Own

The OECD AI Principles are critically important:
- Innovation
- Respect for human rights
- Safety and robustness
- Accountability

None can be denied. Meanwhile, the field raises these concerns:
- "We still don't know what we're supposed to actually do"
- "If we check everything, development stops"
- "We can't judge what's 'enough'"

Principles show the destination, but they don't provide the route (design and operations).

2. Security Alone, Privacy Alone, AI Governance Alone, or Development Experience Alone — None Suffice

AI-era problems cannot be solved through single-domain optimization. Making things work in the field requires redesigning according to the organization and use case. For example: shadow AI inventory → risk classification → exception design → logs/audit trails and responsibility boundaries — restructured to operate within the development process.

Consider your own position. Depending on where your expertise lies, the field tends toward:
- Security perspective only → "Ban everything" becomes the optimal answer
- Privacy perspective only → Doesn't work in practice
- Governance perspective only → Ends in abstraction
- Development perspective only → Risks become invisible
- User perspective only → Convenience wins; rules get circumvented

What's needed is design that understands each domain's logic and finds the balance. This is a domain that can only be mastered through practice, not theory.

3. Not "Don't Let Them Use It" — Create a "State Where They Can Judge"

The common thread in AI governance that works in practice is, when abstracted, surprisingly simple:
- What's OK and what's not
- Where does it require judgment
- Who judges, and who is responsible

These must be defined in advance. Neither blanket prohibition nor leaving it entirely to the field — comprehensive measures that leave room for judgment are needed.

4. Innovation and Safety Are Not a Trade-off

In AI adoption, there appear to be moments where you must choose between innovation and safety/human rights. In practice, however, coexistence is possible through integrated design:
- Clarify the points where human intervention is needed
- Decide judgment and responsibility ownership in advance
- Ensure logs (audit trails) and explainability

These are not conditions for stopping innovation — they are prerequisites for pressing the accelerator with confidence.

5. Checkpoint Perspectives for Measuring Implementability (Excerpts)

Based on the SPA-IT perspective, these are the areas that most commonly become bottlenecks in practice. These are not specific organizational cases but generalized pain points common across multiple field experiences.

In many organizations, operations begin with "exception handling," "audit trails," and "responsibility boundaries" left unstructured — resulting in shadow AI persisting. Therefore, designing inventory and classification, exception operations, and log/audit mechanisms as a continuous whole determines implementability.
- Is the nature of input data organized?
- Where are AI judgment results handed off to humans?
- When unexpected behavior occurs, are there means to stop it?
- In the event of an incident, is the organization in a state to fulfill accountability?

These are not about the type of tool but about "how it's used" and "operations."

Conclusion

AI principles exist to protect human rights and advance adoption. Achieving both in the field requires understanding the principles, the technology, and the organization's reality.

As a starting point for that perspective, we have published an AI Governance / Safety Checklist (Preview edition).

---

References:
- AI Governance & Safety Checklist (Preview) - GitHub (https://github.com/cyber-secure-jp/cyber-secure-txt-files/tree/main/checklists/ai-governance-safety)

---

Disclaimer: This article represents the personal views of the author based on information available as of December 2025, and does not represent the views of any affiliated or related organization.

---
URL: https://cyber-secure.tech/en/insights/university-lecture-2025-12-14
Title: Security Design and AI Governance in the 'Assume Breach' Era: Lessons from 2025 Incidents
Last-Modified: 2025-12-14

Introduction: The Current State of Business Management and Secure Systems

I recently delivered a lecture at Meiji University titled "Business Management and Secure Systems — The Importance and Practice of Information Security." This article uses the 2025 domestic incident cases covered in the lecture as a starting point, organizing from a practitioner's perspective the structural challenge of "why systems fail even at large enterprises with sufficient countermeasures," and the integrated design of "security, privacy, and governance" demanded in the rapidly advancing AI era.

1. Security Is "Mixed Martial Arts" — Single-Point Measures Can't Win

In the lecture, I compared security measures to "Mixed Martial Arts (MMA)" — because no single technology or one-off initiative can handle today's compounding threats in practice. Beyond programming, networking, and security products, one must consider relevant legislation, public relations and crisis response, physical security, and human vulnerabilities.

2. 2025 Cases: Reading "Structure" from Public Disclosures

The lecture used several ransomware cases published in 2025 as case studies. The important focus is not "who got hit" but rather the scope of what stopped, the difficulty of recovery, and where design weaknesses manifested.

Major domestic manufacturer A (September 2025): Public disclosures described unauthorized access and ransomware encryption damage, with potential impact on approximately 1.9 million personal records (aggregating multiple categories). Beyond system downtime business losses, the situation raised questions of social responsibility for privacy violations.

Major domestic retail/logistics company B (October 2025): Ransomware infection caused e-commerce site shutdowns affecting orders and shipments. Recovery required phased service restoration with partial functionality restrictions and manual operations.

These cases demonstrate that once breached, recovery extends long-term with serious impacts on both business continuity and privacy protection.

3. Why "Even Large Enterprises Can't Prevent It": The Swiss Cheese Model

Major incidents rarely result from "a single mistake" — they occur when small holes across multiple defense layers accidentally align, a phenomenon known as the Swiss Cheese Model. This underscores the growing importance of concepts like the cyber kill chain and zero trust as design and operational fundamentals.

Three representative layers that become fatal when they align:
- Entry defense limitations: Email or VPN appliance vulnerabilities allow the first wall to be breached
- Internal defense gaps: Insufficient network segmentation or privileged ID management enables lateral movement
- Recovery design misalignment: Backup data itself is compromised, or recovery procedures don't align with BCP (Business Continuity Plan), prolonging recovery

4. Implementing "Assume Breach" in Practice

Security design going forward requires more than "building higher walls." The recommendation is to design detection, containment, and recovery holistically, assuming breach will occur.
- Read the attack chain: Anticipate attacker behavior (reconnaissance → intrusion → expansion) and design where to break the chain
- Segment lateral movement: Thoroughly implement network segmentation and privilege design, verifying that breach in one area doesn't cascade
- Operate endpoint behavior monitoring: Deploy EDR not as "install and forget" but paired with monitoring, analysis, and response operations (SOC structure, external MDR, etc.)
- Pre-agree on recovery and alternatives: Align RTO (Recovery Time Objective) and RPO (Recovery Point Objective) with management and business units in advance; prepare recovery procedures and alternatives from network-isolated states
- Supply chain assumption: Design with the premise that subcontractors and trading partners can become breach entry points

5. "Defense" in the AI Era: Converging Security, Privacy, and Governance

The latter half of the lecture explored issues accompanying rapid AI adoption. In the AI era, organizations must integrate three perspectives beyond traditional IT security: AI security, privacy, and AI governance.

(1) AI Security and Emerging Threats

AI models themselves are now attack targets. The lecture covered adversarial examples that deceive image recognition and the OWASP Top 10 for LLMs — new threats targeting large language models. Prompt injection and data poisoning attacks in particular cannot be fully blocked by traditional firewalls.

(2) Privacy and Regulatory Compliance (AI Governance)

As AI processes massive amounts of personal data, privacy protection is paramount. International rule-making continues with the EU AI Act, ISO/IEC 42001, and NIST AI RMF, while Japan's AI Business Operator Guidelines also require compliance. Governance ensuring not just usability but legal and ethical safety is essential.

(3) Distinguishing Transparency, Explainability, and Accountability
- Transparency: Disclosing system mechanisms — data sources, algorithm overviews — in understandable form
- Explainability: Being able to explain technically and legally why a specific output was produced
- Accountability: Taking organizational responsibility for development and operational outcomes, ensuring auditability and continuous monitoring

6. Student Q&A (Selected)

Q: I'm considering a career in IT. What preparation is needed?

A: Security, which is essential across IT, is "mixed martial arts" — narrow expertise alone won't suffice. First, build fundamental fitness in IT basics (networking, OS, programming). Then try building a complete application yourself — a three-tier web application plus something using AI fundamentals and popular libraries. Cultivate the "persistence" to stay current with technology and the "communication skills" to discuss technology in business context. Certifications serve as good milestones for systematic learning.

Q: If ransomware actually hits, what should the frontline do?

A: The most critical initial response is containment — preventing damage spread. Isolating the infected terminal from the network (unplugging the LAN cable, etc.) is step one. Hasty reboots can destroy memory-resident evidence, so careful judgment is required. Regarding ransom payment, most governments recommend against it from counter-terrorism financing perspectives. If self-recovery proves difficult, consulting experts or police cybercrime divisions are options.

Conclusion: The Expert's Value Lies in "Comprehensive Capability" and "Practical Effectiveness"

There is no silver bullet in security. What future experts need is comprehensive capability spanning technology, legal, management, and privacy considerations, and practical effectiveness that reliably protects the business in emergencies.
- Security: Design that is "hard to stop, and quick to restore when stopped"
- Privacy: Design that "minimizes individual impact and fulfills accountability"
- AI Governance: Design that "addresses new threats while ensuring auditability of decision processes"

Optimizing these three separately causes rework in field operations — designing them integrated from the start is the practical answer demanded by AI-era security.

Disclaimer: This article represents the personal views of the author based on information available as of December 2025, and does not represent the views of any affiliated or related organization.

---
URL: https://cyber-secure.tech/insights/university-lecture-2025-12-14
Title: 2025年のインシデント事例から学ぶ「侵入前提」時代のセキュリティ設計とAIガバナンス（2025.12.14）
Last-Modified: 2025-12-14

はじめに：経営とセキュアシステムの現在地

先日、明治大学にて「経営とセキュアシステム 〜情報セキュリティの重要性と実践〜」の講義を担当しました。

本記事では、講義で取り上げた2025年の国内インシデント事例を手がかりに、「なぜ十分な対策を持つ大企業でもシステムが止まってしまうのか」という構造的な課題と、急速に普及するAI時代に求められる「セキュリティ・プライバシー・ガバナンス」の統合的な設計について、実務家の観点から整理します。

1. セキュリティは「総合格闘技」──単発の対策では勝てない

講義では、セキュリティ対策を「総合格闘技（MMA）」に例えました 。

単一の技術や単発の施策だけでは、複合化する現代の脅威に対して実務が成立しないためです 。

例えば、プログラミング／ネットワーク／セキュリティ製品といった技術だけでなく、関連法令、広報・危機対応、物理的セキュリティ、人間の脆弱性など、幅広く考える必要がある点を伝えたかったので、あえてこういう例えで説明しました。

2. 2025年の事案：公表情報から読み解く“構造”

講義では、2025年に公表された複数のランサムウェア事案を、ケーススタディとして題材にしました。

ここで重要なのは「どこがやられたか」という目が行きがちな箇所ではなく、止まった範囲と復旧の難しさ、そして設計上の弱点がどこに現れたかというもう少し俯瞰的な観点です。

国内大手製造業A社（2025年9月判明）：

公表情報によれば、不正アクセス等が説明され、ランサムウェアによる暗号化被害が示されています。

ここで特筆すべきは、約190万件規模（複数区分の公表件数を合算）の個人情報に関する影響可能性が公表された点です。

システム停止によるビジネス損失だけでなく、プライバシー侵害という社会的責任が問われる事態となりました 。

国内大手流通サービス業B社（2025年10月判明）：

公表情報によれば、ランサムウェア感染により、ECサイト等が停止し、注文・出荷等に影響が生じました。

復旧にあたっては、一部機能制限や手作業での運用を併用しながら、段階的にサービスを再開させるという苦しい対応を迫られました。

これらの事例からは、ひとたび侵害されれば復旧が長期化し、事業継続とプライバシー保護の両面で深刻な影響が出るという現実が見て取れます。

3. なぜ「大企業でも防げない」のか：スイスチーズモデルで捉える

大規模なインシデントは、「どこか1つのミス」で起きるというよりも、複数の防御層にある小さな穴が偶然一直線に並んでしまういわゆる「スイスチーズモデル」の崩壊によって発生します。

これは、サイバーキルチェーンやゼロトラストといった考え方が、設計・運用の前提として重要性が増していることを意味します。

学生にもわかりやすく説明するため、無数にある論点のうち代表例として、以下の3つが重なると致命傷になり得る、と簡易的に説明しました。

入口防御の限界： メールやVPN機器の脆弱性など、最初の壁を突破される。

内部防御の穴： ネットワークの分割や特権ID管理に隙があり、侵入後の横展開（ラテラルムーブメント）を許してしまう。

復旧設計の不整合： バックアップデータ自体が被害を受ける、あるいは復旧手順がBCP（事業継続計画）と噛み合っておらず、復旧が長期化する。

4. 「侵入前提（Assume Breach）」を実装に落とす

これからのセキュリティ設計は「壁を高くする」だけでは足りません。

推奨しているのは、侵入を前提に、検知・封じ込め・復旧までを一貫して設計することです。

攻撃の連鎖を読む： 偵察→侵入→展開といった攻撃者の行動（サイバーキルチェーン）を想定し、どの段階で攻撃を断ち切るかを設計します 。

横展開を分断する： ネットワークのセグメンテーションと権限設計を徹底し、侵入されても被害が全体に波及しないよう点検します。

端末の挙動監視を回す： EDR（Endpoint Detection and Response） などを、「導入して終わり」にせず、監視・分析・対応の運用（SOC体制、外部MDR活用等）とセットで機能させます。

復旧・代替の合意を先に作る： RTO（目標復旧時間） や RPO（目標復旧時点） を経営・事業部門と事前に合意し、ネットワークを隔離した状態からの復旧手順・代替手段を用意します 。

サプライチェーン前提： B社の関連事例（物流委託先でのインシデント）のように、委託先や取引先が攻撃の突破口になることを前提に設計します 。

5. AI時代の「守り」：セキュリティ・プライバシー・ガバナンスの融合

講義の後半では、急速に進むAI活用に伴う論点を掘り下げました。

AI時代においては、従来のITセキュリティに加え、AIセキュリティ、プライバシー、そしてAIガバナンスの3つの観点を統合する必要があります 。

(1) AIセキュリティと新たな脅威

AIモデル自体が攻撃対象となる時代です。講義では、画像認識を欺く「Adversarial Examples（敵対的サンプル）」 や、大規模言語モデル（LLM）に対する新たな脅威をまとめた 「OWASP Top 10 for LLM」 を紹介しました 。

特にプロンプトインジェクション や データポイズニング（学習データ汚染） といった攻撃は、従来のファイアウォールでは防ぎきれず、AI特有の対策の重要性が増しています。

(2) プライバシーと規制対応（AIガバナンス）

AIが個人データを大量に学習・処理する中で、プライバシー保護は最重要課題です。

「EU AI Act（欧州AI法）」 や 「ISO/IEC 42001」、「NIST AI RMF」 といった国際的なルール形成が進んでおり、日本でも「AI事業者ガイドライン」 への準拠が求められます。

単に「使える」だけでなく、「法的に、倫理的に安全か」を担保するガバナンス体制が必須となります。

(3) 透明性・説明可能性・説明責任の区別

AIガバナンスを設計する上で、講義では以下の3つを明確に区別して定義しました 。

透明性 (Transparency)： データソースやアルゴリズムの概要など、システムの仕組みを理解可能な形で開示すること。

説明可能性 (Explainability)： 特定の出力結果に至った理由を、技術的・法的に説明できる状態にすること。

説明責任 (Accountability)： 組織として開発・運用の結果に責任を持ち、監査可能性や継続的な管理（モニタリング）を担保すること。

ツールを導入するだけでなく、最終的には「組織としてどう責任を持つか」という設計が問われます。

6. 学生からのQ&A

学生から多くの質問をいただきましたので抜粋してこちらにも共有させていただきます。

Q. IT業界への就職を考えています。どのような準備が必要ですか？

A. IT業界の中でも必須であるセキュリティは「総合格闘技」とお話しした通り、狭い専門知識だけでは戦えません。まずはIT全般（ネットワーク、OS、プログラミング）の基礎体力をしっかりつけることが重要です。 その上で、自分で一度アプリケーションをひと通り作ってみること。現在であればWeb系の3層アプリケーションに加え、AIの基礎理論や有名なライブラリを使って「動くもの」を作ってみてください。 そして、最新技術へのアンテナを張り続ける「継続力」と、技術をビジネスの文脈で語れる「コミュニケーション力」を磨くこと。資格（情報処理安全確保支援士など）は、その体系的な学習の良いマイルストーンになります。

Q. 実際にランサムウェアに感染したら、現場ではどう動くべきですか？

A. 初動で最も重要なのは「被害拡大の防止（封じ込め）」です。感染端末をネットワークから隔離（LANケーブルを抜く等）することが第一歩。安易に再起動するとメモリ上の痕跡（証拠）が消えるため、慎重な判断が求められます。 身代金の支払いについては、テロ資金供与対策等の観点から多くの政府が「支払わない」ことを推奨しています。自力での復旧が困難な場合は、専門家への相談や警察のサイバー犯罪相談窓口も選択肢に入ります。

まとめ：専門家の価値は「総合力」と「実効性」にある

セキュリティ対策に"銀の弾丸"はありません。

これからの専門家に求められるのは、技術・法務・経営・プライバシー配慮を俯瞰する「総合力」と有事の際にビジネスを確実に守る「実効性」です。
- セキュリティは「止めにくく、止まっても早く戻す」設計
- プライバシーは「個人への影響を最小化し説明責任を果たす」設計
- AIガバナンスは「新たな脅威への対応と、判断プロセスの監査可能性を両立する」設計
これら三者を別々に最適化すると現場運用で手戻りが起きるため、最初から統合して設計する——

これが、AI時代のセキュリティに求められる実務的解答だと考えています。

免責事項

本検証は2025年12月時点の情報に基づいた筆者個人の見解であり、所属組織・関係組織の見解ではありません。

---
URL: https://cyber-secure.tech/insights/ai-web-value-2025-11-03
Title: AI時代におけるWeb価値構造の二極化：実務的な考え方（2025.11.03）
Last-Modified: 2025-11-03

はじめに

CloudflareのCEOによる警鐘を機に、Webコンテンツと検索エンジン間の「価値交換の崩壊」が議論されている事をフロントエンドエンジニアの友人から聞き気になったのでちょっと調べてみました。

内容としては、AIモデルによる過剰なクローリングと、検索結果上で回答が完結するゼロクリック検索の増加により、従来の広告モデルや検索流入に依存したビジネスは存続の危機にあると言う事です。フロントエンジニアでマーケティングを踏まえた視点からみた友人（コンテンツ作成者でCVやLTVの数値が指標になる立ち位置）と、私のようなサーバサイドをバックグラウンドにしたAIガバナンスやセキュリティなどの専門家の観点で話が噛み合わなかったので軽く調べてみた次第です。

この構造変化の本質は「Web全体の崩壊」ではなく、Web上の価値構造が概ね二つに整理できると考えます。コンテンツ制作者やビジネスオーナーは、自社の価値がどちらの領域に属するかを見極めることが、AI時代を生き抜くための最初の実務判断となるでしょう。

価値構造の二極化：残る価値と崩れる構造

Webの価値は、簡略化して考えた場合概ね２つに分類すると考えるとわかりやすいと思います。

1. 影響を受けにくい領域：直接的な訪問と行動が価値を生む構造

この領域は、ユーザーが「具体的な行動」や「ログイン」を伴うことで価値が成立する構造です。AIが情報を要約しても、最終的な目的達成のためにはサイト訪問が不可欠であり、価値がAIに代替されません。

具体的なビジネス例：

トランザクション・ドリブン: EC（電子商取引）、予約サービス、決済システムなど。
クローズド・コミュニティ: 会員制データベース、専門コミュニティ、ログインが必要なSaaSなど。

価値が残る理由：

ユーザーのニーズが「情報取得」で完結せず、「購入」「予約」「手続き」「体験」「ログイン後の利用」へと繋がるため。AIはナビゲーターに留まり、コンバージョン（CV）は引き続きサイト上で発生します。

2. 影響を受けやすい領域：AIが中間層として代替可能な構造

この領域は、主に「情報検索」に応えることを目的とし、トラフィックと広告収益に依存してきた構造です。AIが情報を収集・要約し、ユーザーに直接提供することで、従来のサイト訪問（PV）は激減します。

具体的なビジネス例：

オープン・インフォメーション:ニュースメディア、汎用性の高いQ&Aサイト、SEO特化型のブログ、アフィリエイト情報サイトなど。

構造が崩れる理由：

ユーザーのニーズがAI回答の「入口」で完結し、サイト訪問が不要になるため。特に、事実情報や汎用的な知識、容易に要約できるコンテンツは、AIによる代替の直撃を受けます。

コンテンツ制作者が取るべき実務戦略

AI時代のコンテンツ戦略は、価値を脆弱な領域からレジリエントな領域へとシフトさせることに尽きます。

1. 「要約されない独自性」を追求する

AIに容易に代替される「汎用情報」から、筆者の経験、専門的な洞察、人間的な物語性、感情の温度といった「AIが再現しにくい要素」を伴うコンテンツへと軸足を移します。読者が「AIの回答ではなく、この人の視点が必要だ」と感じる、不可逆的なブランドと信用の確立が不可欠です。

2. オープンとクローズドを戦略的に使い分ける

集客用の一般情報はオープンにして発見性を確保しつつ、核となる価値部分（専門的なツール、詳細データ、コミュニティ）はログイン後や会員限定のクローズドな環境で提供するモデルへと移行します。

3. テクノロジーで価値を主張する

AIクローラーのアクセスを制御する技術的対策（robots.txtを用いた特定のAIクローラーのブロック、Cloudflareのクローラー制御機能など）を講じることで、無断収集を拒否し、データ利用に対価を求める権利を主張します。また、業界全体のライセンススキーム（例：llms.txtなどの提案）の整備動向にも着目し、参画していく必要があります。

結論：価値の源泉を再定義する

AI時代における実務判断の要諦は、「コンテンツの価値が、AIを経由せずともユーザーを直接引きつけられるか」という点に集約されます。

Web上の価値は「トラフィック量」から「提供する体験とLTV」へと移行しています。コンテンツ制作者は、単にアクセス数を追うのではなく、「AIでは提供できない、ユーザーとの直接的な関係性」の中に持続可能なビジネスの源泉を再定義し、戦略をアップデートしていくことが求められます。

注記：本稿で引用したデータや発言は、2025年5月から9月にかけての公開情報に基づいています。AI技術とWeb経済の状況は急速に変化しており、最新情報の確認を推奨します。また本記事の一部はAIにより作成しています。自身の責任においてご参照の上活用ください。

---
URL: https://cyber-secure.tech/en/insights/ai-web-value-2025-11-03
Title: The Polarization of Web Value in the AI Era: A Practical Perspective
Last-Modified: 2025-11-03

Introduction

Prompted by Cloudflare's CEO raising alarms, the "collapse of value exchange" between web content and search engines has become a topic of discussion — something a front-end engineer friend brought to my attention. The core issue: excessive crawling by AI models and the rise of zero-click searches (where answers are completed in search results) threaten businesses that depend on traditional advertising models and search-driven traffic.

My friend (a content creator focused on metrics like CV and LTV from a front-end/marketing perspective) and I (with a server-side background specializing in AI governance and security) found ourselves talking past each other — so I did some research.

The essence of this structural change is not "the collapse of the entire Web" but rather that the value structure on the Web can be organized into roughly two categories. For content creators and business owners, discerning which domain their value belongs to is the first practical decision for surviving the AI era.

The Polarization of Value: What Survives and What Crumbles

1. Resilient Domain: Where Direct Visits and Actions Generate Value

This domain is structured so that value is established when users take "concrete actions" or "log in." Even if AI summarizes the information, site visits remain essential for achieving the ultimate purpose — value cannot be substituted by AI.

Examples: Transaction-driven businesses (e-commerce, booking services, payment systems); closed communities (member-only databases, specialized communities, SaaS requiring login).

Why value persists: User needs do not end at "information retrieval" — they extend to purchasing, booking, completing procedures, experiencing, and using services after login. AI remains a navigator; conversions still occur on-site.

2. Vulnerable Domain: Where AI Can Substitute as an Intermediary

This domain primarily serves "information retrieval" needs and has depended on traffic and advertising revenue. When AI collects, summarizes, and directly delivers information to users, traditional site visits (PVs) plummet.

Examples: Open information sites (news media, general Q&A sites, SEO-focused blogs, affiliate information sites).

Why the structure crumbles: User needs are completed at the "entry point" of AI answers, making site visits unnecessary. Factual information, general knowledge, and easily summarized content are directly impacted by AI substitution.

Practical Strategies for Content Creators

Content strategy in the AI era comes down to shifting value from vulnerable domains to resilient domains.

1. Pursue "Uniqueness That Cannot Be Summarized"

Shift from "general information" easily substituted by AI to content that carries elements AI cannot replicate — the author's experience, specialized insight, human narrative, and emotional texture. Establishing an irreversible brand and credibility where readers feel "I need this person's perspective, not an AI's answer" is essential.

2. Strategically Separate Open and Closed Content

Keep general information open for discoverability, while migrating core value (specialized tools, detailed data, communities) to closed environments behind login or membership barriers.

3. Assert Value Through Technology

Implement technical measures to control AI crawler access (blocking specific AI crawlers via robots.txt, Cloudflare crawler control, etc.) to refuse unauthorized collection and assert the right to demand compensation for data usage. Also track industry licensing scheme developments (e.g., llms.txt proposals).

Conclusion: Redefine the Source of Value

The key practical judgment in the AI era is: "Can your content's value directly attract users without going through AI?" Web value is shifting from "traffic volume" to "the experience provided and LTV." Content creators must stop merely chasing pageviews and instead redefine sustainable business sources within "direct relationships with users that AI cannot provide."

Note: Data and statements cited in this article are based on publicly available information from May to September 2025. The AI technology and web economy landscape is changing rapidly; verification of the latest information is recommended. Portions of this article were created with AI assistance. Please reference and use at your own discretion.

---
URL: https://cyber-secure.tech/en/insights/llm-info-discovery-comparison-2025-07-06
Title: Can You Trust LLM Information Retrieval? A Comparative Analysis of Major AI Search Capabilities
Last-Modified: 2025-07-06

Introduction

As AI adoption accelerates, we increasingly encounter the challenge of "what constitutes optimal website design for AI." As a follow-up to our previous insight article, this piece compiles additional findings, including somewhat technical aspects of web crawling, based on evaluation experiments where multiple AIs assessed the same site.

The result: ChatGPT was able to read page structure and documented information to a reasonable degree, while Claude could only retrieve partial information and appeared unable to grasp the site's overall content. What causes this significant gap?

Investigation revealed major differences in the search engines each AI uses, technical constraints, and their ability to handle site structures. Particularly interesting was the fact that even with properly placed sitemaps registered with major search engines, some AIs couldn't discover even basic information.

In business today, we frequently hear "I checked with ChatGPT" or "AI evaluated it." But if the information and evaluations obtained vary dramatically depending on which AI is used, this is a serious problem. Understanding each AI's characteristics and using them selectively has become essential for accurate information gathering and appropriate judgment.

Test Overview

Target LLMs: ChatGPT (OpenAI/GPT-4o), Claude (Anthropic/Sonnet 4), Gemini (Google), Perplexity (Perplexity AI), supplementary: GenSpark

Using identical prompts across LLMs against our domain, we observed response content structure and information retrieval tendencies.

Key evaluation criteria:
- Information discovery scope: How much page content and structure could be accessed
- Information consistency: Alignment between response content and actual page descriptions
- Response consistency: Whether outputs were consistent under identical conditions
- Search depth: Ability to reach internal pages and hierarchical structures

Results

ChatGPT: Demonstrated broad information retrieval across the entire site, incorporating content from multiple pages. Showed reasonable capability in structure comprehension and context reflection.

Claude: Limited information retrieval scope; most major content was inaccessible. Initial responses contained almost no site-specific information, revealing challenges in structural recognition depth.

Gemini: Some sites and content were retrieved, but overall cross-page information integration and context comprehension appeared limited. Response to information structures was somewhat restrained.

Perplexity: Retrieved information showed variability, with some responses mixing in external sources. As a multi-source integration model, some challenges remained regarding information consistency and source stability.

GenSpark: Showed strong tendency toward accessing external resources (e.g., official sites and off-site data), with retrieval behavior combining internal site information with external data.

Why Differences Arise Between LLMs

Search engine differences: ChatGPT uses Bing, Gemini uses Google, Claude uses Brave Search, and Perplexity uses a multi-source integrated approach. Significant differences exist in index scope, reflection speed, and real-time capability.

Technical constraints: Some LLMs can only crawl URLs displayed in search results, with limitations on reaching subdirectories, redirect destinations, and specific file formats.

Index reflection speed: Some search engines take time to index new files, and sitemap registration and structured data may not be reflected immediately.

Countermeasures for AI-Era Website Design

Multi-LLM Compatibility Strategy
Place important information across multiple paths and pages, actively utilize structured data, and clearly document essential information in sitemaps and top pages to ensure accessibility for each LLM.

Addressing Search Constraints
Place important information directly under the root, avoid excessive use of subdirectories and redirects, and adopt simple, clear site structures.

Search Engine Optimization
Proper registration with Google Search Console, Bing Webmaster Tools, etc., comprehensive sitemaps and structured data, and clear navigation design improve discoverability across search engines.

Information Redundancy
Provide important information across multiple pages in different formats, enabling information access suited to each LLM's search characteristics.

Conclusion

This investigation revealed clear differences in how each LLM retrieves information and what scope is visible to it. No AI can "accurately retrieve all information" — each has strengths and weaknesses. When researching, comparing results across multiple AIs rather than relying on just one can lead to more reliable understanding.

For information publishers as well, designing with "AI-friendly structure" in mind can help ensure intended content is more accurately retrieved. However, no matter how much optimization is applied, what ultimately matters is that the information is "useful to the reader." Creating content that communicates clearly to both AI and humans will become increasingly important going forward.

Disclaimer: This investigation is based on a specific site as of July 2025, and results may not be identical for all sites. Each LLM's capabilities are continuously improving, so current conditions may differ. Results are also expected to vary significantly based on site structure, content, and industry characteristics. When referencing this article, periodic re-verification and comprehensive evaluation across multiple criteria are recommended. Multiple LLMs were used in writing this article.

---
URL: https://cyber-secure.tech/insights/llm-info-discovery-comparison-2025-07-06
Title: LLMの情報収集能力は本当に信頼できるのか？主要AI4社の検索性能を徹底比較検証（2025.07.06）
Last-Modified: 2025-07-06

はじめに

AIの活用が急速に進む中、「AIにとって最適なWebサイト設計とは何か」という課題に直面する機会が増えています。

先日公開したinsight記事の続編として、判明した追加の知見をもとに本稿をまとめました。

Webクローリングなど少し突っ込んだ内容を検証しつつ複数のAIによる同一サイトの評価実験を行ったところ以下の結果が出たので公開してみたいと思います。

結果として、ChatGPTはページ構造や記載された情報をある程度読み取れていましたが、Claudeは一部の情報しか取得できず、サイト全体の内容を把握できていないようでした。
この大きな差は一体何が原因なのでしょうか。

調査を進めると、各AIが使用する検索エンジンの違い、技術的制約、そしてサイト構造への対応能力に大きな差があることが明らかになりました。特に興味深いのは、サイトマップを適切に配置し、主要検索エンジンに登録していても、一部のAIでは基本的な情報すら発見できないという事実でした。

現在、ビジネスの現場では「ChatGPTで調べました」「AIが評価しました」という言葉をよく耳にします。しかし、どのAIを使うかによって得られる情報や評価が大きく変わるとすれば、これは深刻な問題です。正確な情報収集と適切な判断のためには、各AIの特性を理解し、使い分けることが不可欠となってきています。

AI（LLM：Large Language Model）による情報収集や調査が当たり前になりつつある今、「AIが自社サイトをどのように認識しているか」は重要な課題です。本記事では、主要LLM（ChatGPT、Claude、Gemini、Perplexity）による実際の情報発見・評価プロセスを検証し、その違いと対策を紹介します。

検証概要

対象LLM

・ChatGPT（OpenAI／GPT-4o）

・Claude（Anthropic／Sonnet 4）

・Gemini（Google）

・Perplexity（Perplexity AI）

・補足検証：GenSpark

当サイトのドメインに対して、各LLMに同一のプロンプトを用いて情報取得を試みた。

内容に関する調査を促す形式のプロンプトを提示し、応答内容の構造や情報の取得傾向を観察した。

主な観点は以下の通り：
- 情報発見範囲：どの程度の記述内容やページ構造にアクセスできたか
- 情報の整合性：応答に含まれる内容と、実際のページ記述との一致度
- 応答の一貫性：同一条件下での出力内容に一貫性があるかどうか
- 検索挙動の深度：内部ページや階層構造への到達状況

検証結果

ChatGPT
サイト全体にわたり情報の取得範囲が広く、構成上の複数ページから記述内容を取り込んでいる様子が確認された。構造把握および文脈の反映にも一定の対応が見られた。

Claude
 情報の取得範囲が限定的で、主要な記述内容の多くにアクセスできていなかった。初回応答ではサイト固有の情報に基づく内容がほとんど含まれておらず、構造認識の深さに課題が見られた。

Gemini
 一部のサイトや記述は取得されていたが、全体としてはページ横断的な情報統合や文脈の把握には至っていない印象だった。情報構造への反応はやや控えめ。

Perplexity
 取得情報にばらつきがあり、外部ソースと混同された応答が確認される場面もあった。複数ソース統合型であることから、情報の整合性や出典の安定性にやや課題が残った。

GenSpark
 外部リソース（例：公式サイトやサイト外部データ）に対するアクセス傾向が強く、サイト内部の情報と外部情報を組み合わせた取得挙動が確認された。

LLMごとの違いが生まれる理由

検索エンジンの違い ChatGPTはBing、GeminiはGoogle、ClaudeはBrave Search、Perplexityは複数統合型をそれぞれ使用。インデックス範囲や反映速度、リアルタイム性に大きな差が存在する。

技術的制約 一部のLLMでは検索結果に表示されたURLのみクロール可能という制約や、サブディレクトリやリダイレクト先への到達の制限、特定ファイル形式のアクセス制限などが確認された。

インデックス反映速度 検索エンジンによっては新規ファイルのインデックス化に時間がかかるケースがあり、サイトマップ登録や構造化データも即時反映されない場合が見られた。

AI時代のWebサイト設計に求められる対策

マルチLLM対応の基本戦略
重要情報を複数パス・複数ページに配置し、構造化データを積極的に活用する。サイトマップやトップページに必須情報を明記し、各LLMがアクセスしやすい設計を心がける。

検索制約への対応
ルート直下への重要情報の配置、サブディレクトリやリダイレクトの多用回避、シンプルで分かりやすいサイト構造の採用などが有効。技術的制約を考慮した設計が重要。

各検索エンジンへの最適化
Google Search ConsoleやBing Webmaster Tools等への適切な登録、サイトマップや構造化データの充実、明快なナビゲーション設計により、各検索エンジンでの発見可能性を向上させる。

情報の多重配置
重要な情報は、複数のページで異なる形式で提供し、LLMの検索特性に応じた情報アクセスを可能にする。

結論

今回の検証により、LLMごとに情報の拾い方や見えている範囲には明確な違いがあることが分かりました。どのAIも「すべての情報を正確に取得できる」わけではなく、それぞれ得意・不得意があります。

調べごとをする際には、ひとつのAIだけに頼るのではなく、複数のAIを使って見比べることで、より確かな理解につながる可能性があります。

また、情報を発信する側にとっても「AIにとっても分かりやすい構成」を意識することで、伝えたい内容がより正確に拾われやすくなることが期待されます。

ただし、どれだけ工夫を凝らしても、最終的に大切なのは「読む人にとって役に立つ情報」であることに変わりはありません。AIにも人にも伝わりやすい内容を心がけることが、今後ますます重要になっていくでしょう。

免責事項

本検証は2025年7月時点の特定サイトでの事例であり、すべてのサイトで同様の結果になるとは限りません。各LLMの性能は継続的に改善されているため、現在の状況とは異なる可能性があります。また、サイトの構造や内容、業界特性によっても結果は大きく変わることが予想されます。

本記事の内容を参考にする際は、定期的な再検証と、複数の評価軸による総合的な判断を行うことを推奨します。

また、本記事の執筆には複数のLLMを利用しています。

---
URL: https://cyber-secure.tech/en/insights/llm-site-access-test-2025-07-03
Title: AI-Era Web Crawling Verification: Which Websites Can LLMs Actually Read? — Comprehensive Access Test Results Using a Hybrid-Architecture Site
Last-Modified: 2025-07-03

Introduction

As large language models (LLMs) such as ChatGPT, Claude, and Gemini become widespread, many website operators are asking: "How much of my website can AI actually read?"

I had this same question and decided to conduct an actual verification. Being an AI training target carries both benefits — broader information dissemination and increased recognition for those publishing specialized information — and concerns about unintended usage or inaccurate information generation.

However, accurate information about actual LLM access behavior is limited, with much speculation and conjecture circulating. So I used my own website to empirically verify whether LLMs can actually access it.

Test Site Architecture

The verification target was my own website.
- Domain: Security, privacy, and AI governance
- Technical architecture: Hybrid (multi-domain site: static hosting + CMS combination)

Architecture overview:

Root domain (static hosting service):
- /llms.txt (AI-oriented sitemap)
- /robots.txt (crawler control)
- /.well-known/security.txt (RFC 9116 compliant)
- Redirect configuration

www subdomain (no-code CMS):
- / (top page)
- /XXXX/ (content page 1)
- /YYYY/ (content page 2)
- /ZZZZ/ (content page 3)

Test Method and Results

Test Overview

LLMs tested: ChatGPT, Claude (Anthropic), Gemini

Note: This tested not the LLMs' direct web crawling capabilities, but their ability to retrieve information through the web access features they provide (web search plugins, etc.).
- Test method: Information retrieval through each LLM's web access features (web search plugins, etc.)
- Test date: July 3, 2025 (setup performed on July 2)

Successful Access (Excerpts)

The following content was successfully accessed (though results varied by LLM — e.g., some LLMs could not view CMS content):

Access Failures

The following types of access failures were confirmed:

Inaccessible public pages with specific URL patterns: Some LLMs reported certain public pages with specific URL patterns as "inaccessible." These pages actually required no authentication and had no crawl-blocking settings in robots.txt or llms.txt. This was likely due to temporary web retrieval failures on the LLM side, or a Pattern-Matching Bias where the AI misidentified pages as "private" based on certain strings in the URL. Since access intermittently succeeded and failed, the exact cause remains unclear.

Temporary errors: Errors likely attributable to DNS propagation delays immediately after setup, delayed server certificate provisioning, and unexplained 500-series errors on the CMS side also occurred.

Test Results

This verification revealed the following about LLM website access:

LLMs Can Read No-Code CMS Content (With Occasional Errors)

Verified result: LLMs can access content built on major no-code CMS platforms. As long as the final HTML output is properly structured, LLMs can read the information without issues. However, multiple instances of errors occurring even after successful reads were experienced.

AI Can Read Dynamically Generated Sites

Verified result: LLMs successfully retrieved CMS content that relies on JavaScript for dynamic generation. Modern LLM crawlers have evolved to broadly support many dynamic sites. Again, errors after successful reads occurred multiple times.

Stumbling Points

Several technical challenges were encountered during verification:

1. Understanding Domain Architecture

Challenge: Difficulty determining how to structure the relationship between subdomains and root domains. Since system files couldn't be placed directly in the CMS's design section, domain separation was necessary.

Solution: Proper redirect configuration on the root domain side enabled integrated management and operation of both domains.

2. Placing RFC-Compliant Files

Challenge: When attempting to place RFC-compliant special files like the .well-known directory, some hosting services treated files and directories beginning with "." as private (some SaaS platforms don't display them).

Solution: Migrating to a hosting service that properly supports .well-known directory placement achieved standards compliance.

3. Automatic SSL Certificate Issuance

Challenge: DNS propagation delays prevented automatic SSL certificate issuance from reflecting immediately. Repeated reloading and clicking didn't change the situation.

Solution: Waiting for time to pass (up to approximately 24 hours) allowed DNS propagation and automatic SSL certificate issuance to complete, resolving the issue.

Note: Since errors occurred even after LLMs could read the site, troubleshooting was sometimes difficult.

Controlling LLM Training Access

As website operators, there are cases where you want to show content to LLMs and cases where you don't. Here are countermeasures for each scenario. (Since confirming whether content actually became a training target takes time, this article covers theory only.)

When You Want LLMs to See Your Content
- Explicit permission in robots.txt: Allow crawlers access to the entire site or specific paths. This is the fundamental instruction for LLMs to discover content.
- Organized HTML/URL structure: Use semantic HTML and logical URL structures so LLMs can easily understand content structure.
- Content quality: Providing high-quality content with strong expertise and trustworthiness is most important.
- Preparing for future AI optimization via llms.txt: Use llms.txt files to explicitly indicate your intention to permit LLM training. This complements robots.txt and conveys more granular intent. (Note: This is currently a proposed standard without official support from major LLMs.)

When You Don't Want LLMs to See Your Content
- Explicit bot rejection in robots.txt: Deny specific LLM crawlers or all crawlers access to the entire site or specific paths.
- Authentication restrictions: Pages requiring login (member-only content) won't be crawled by LLMs.
- JavaScript obfuscation (unverified): Heavily obfuscated content using JavaScript may be difficult to crawl. (However, this is unverified, and modern crawlers have strong JavaScript parsing capabilities, making this an unreliable method.)

Configuration Examples

Promoting training access — robots.txt example:
``
User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: 
Allow: /
`

Plus detailed guidance in llms.txt (e.g., training permission statements, credit display requests, citation rules).

Preventing training access — robots.txt example:
`
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: 
Disallow: /
`

Plus noindex meta tag on each page:
`html
<meta name="robots" content="noindex">
``
(Prevents search engines and LLMs from indexing the page.)

Key Findings

This verification yielded the following important insights about the relationship between LLMs and websites:
- Modern LLMs have evolved: They flexibly accommodate diverse hosting formats and CMS technologies, with the ability to crawl many websites.
- Importance of robots.txt: Confirmed once again that robots.txt is the most reliable and standard means of controlling LLM access.
- Effectiveness of hybrid architecture: Even hybrid configurations combining static hosting and CMS can be accessed by LLMs without technical issues.
- Declaring intent to LLMs: Using llms.txt to clearly communicate your intention to permit or deny training is worth considering, though its practical effectiveness requires future verification.
- Adapting to the AI era: Proper response to LLMs is connected not only to SEO (Search Engine Optimization) but also to new concepts like GEO (Generative Engine Optimization).

Conclusion

This empirical verification made the following points clear:
- Modern LLMs can access a wider variety of website technologies than imagined (though access capabilities and results may vary by LLM).
- Intentional configuration by site operators is more important than technical constraints for controlling access.
- With proper design, it is possible to strategically control the relationship with AI.
- Even when browser access works without issues, LLM access may encounter 500 errors after confirming 200 access success — keep this in mind during verification.

As an AI-era web strategy, I strongly feel that balancing "information design assuming you will be learned from" with "a controllable publication policy" is becoming increasingly important.

About the Test Data

This article is written based on actual access test results.

Disclaimer

This article reflects verification results using specific services at a specific point in time, and the author assumes no responsibility for the accuracy, completeness, or applicability of its content to any particular situation.

The writing process for this article includes the use of AI. The ultimate validity and applicability of the content should be evaluated at the reader's own judgment and responsibility.

---
URL: https://cyber-secure.tech/insights/llm-site-access-test-2025-07-03
Title: AI時代のクローリング技術検証 : LLMは実際にどのWebサイトを読み取れるのか？〜ハイブリッド構成サイトを使った包括的アクセステスト結果〜（2025.07.03）
Last-Modified: 2025-07-03

はじめに

ChatGPT、Claude、Geminiなどの大規模言語モデル（LLM）が普及する中、「自分のWebサイトがAIにどこまで読まれているのか？」という疑問を持つサイト運営者の方は多いのではないでしょうか。自分もふとこの疑問を抱き、実際に検証を行ってみました。

AIの学習対象になることは、専門性の高い情報を発信する立場にとって、情報の拡散や認知度向上といったメリットと、意図しない利用や誤った情報の生成への懸念といったデメリットの両方があります。しかし、実際のLLMアクセス状況についての正確な情報は限られており、推測や憶測に基づく情報が多く流通しているのが現状です。

そこで今回、実際に自分のWebサイトを使用して、LLMが本当にアクセス可能なのかを実証的に検証しました。

検証対象サイトの構成

今回の検証対象は、自分のWebサイトです。
- 分野: セキュリティ・プライバシー・AIガバナンス
- 技術構成: ハイブリッド型（複数ドメインを持つサイト：静的ホスティング + CMSの組み合わせ）

構成（抜粋）
- ルートドメイン (静的ホスティングサービス)
- /llms.txt (AI向けサイトマップ)
- /robots.txt (クローラー制御)
- /.well-known/security.txt (RFC 9116準拠)
- リダイレクト設定
1. wwwサブドメイン (ノーコードCMS)
- / (トップページ)
- /XXXX/ (コンテンツページ1)
- /YYYY/ (コンテンツページ2)
- /ZZZZ/ (コンテンツページ3)

検証方法と結果

検証実施概要
- 検証に使用したLLM: ChatGPT, Claude (Anthropic), Gemini
※LLMの直接的なWebクローリング能力ではなく、各LLMが提供するWebアクセス機能（Web検索プラグイン等）を用いた情報取得能力を検証
- 検証方法: 各LLMが提供するWebアクセス機能（Web検索プラグイン等）を通じた情報取得
- 検証日時: 2025年7月3日（設定作業は7月2日に実施）

アクセス成功一覧（抜粋）

以下のコンテンツへのアクセスに成功。（ただし、結果はLLMによって異なる場合あり。例：一部LLMはCMSコンテンツは見れなかった等）

ファイル: ホスティング / 結果 / 取得内容

llms.txt: 静的 / 成功 / LLMによるコンテンツ利用ポリシー

robots.txt: 静的 / 成功 / クローラー許可設定

.well-known/security.txt: 静的 / 成功 / セキュリティ連絡先

トップページ: ノーコードCMS / 成功 / 全文取得

コンテンツページ（複数）: ノーコードCMS / 成功 / 詳細情報

アクセス失敗

今回のテストでは、以下のタイプのアクセス失敗が確認されました。
- 特定のURLパターンを持つ公開ページへのアクセス不可
一部のLLMからは、特定のURLパターンを含む公開ページへのアクセスが「不可」と報告されるケースがありました。これらのページは実際には認証不要であり、robots.txtやllms.txtでのクロール拒否設定もありません。これはLLM側の一時的なWeb情報取得失敗、またはURLに含まれる特定の文字列からAIが「非公開ページ」と誤認してしまうバイアス（Pattern-Matching Bias）によるものと考えられますが、見れたり見れなかったりしましたので明確な理由は不明。
- 一時エラー
作業直後のDNS反映や、サーバ証明書設定遅れによると考えられるエラー、CMS側での500番台エラーなど原因が明確ではない一時エラーも発生

検証結果

今回の検証で、LLMのWebサイトアクセスに関して以下が明らかになりました。

LLMはノーコードCMSを読める（が、時々エラーになることもある）
- 実証結果: 主要なノーコードCMSで構築されたコンテンツにも、LLMはアクセス可能。
- 正確な状況: 最終的にHTMLが出力され、それが適切に構造化されていれば、LLMは問題なく情報を読み取ることができます。ただし、実際にLLMがサイトを読めた後でもエラーになるケースを複数回経験。

動的生成サイトでもAIは読める
- 実証結果: JavaScriptに依存して動的に生成されるCMSコンテンツも、LLMは正常に取得。
- 正確な状況: 現代のLLMクローラーは進化しており、多くの動的サイトに幅広く対応しています。ただし、実際にLLMがサイトを読めた後でもエラーになるケースを複数回経験。

つまずいたポイント

検証を進める中で、いくつかの技術的な課題に直面しました。

1. ドメイン構成の理解
- 課題: サブドメインとルートドメインの関係性をどのように構築するかで悩みました。特に、CMSのデザイン部分にシステムファイルを直接配置できないため、ドメインを分離する必要がありました。
- 解決: ルートドメイン側で適切なリダイレクト設定を行うことにより、両ドメインを統合的に管理・運用できるようになりました。

2. RFC準拠ファイルの配置
- 課題: .well-knownディレクトリのようなRFC（Request For Comments）に準拠した特殊なファイルを配置しようとした際、一部のホスティングサービスでは.で始まるファイルやディレクトリが非公開扱いとなる（SaaSによっては表示させない）問題に直面しました。
- 解決: .well-knownディレクトリの配置に適切に対応しているホスティングサービスへ移行することで、標準準拠を実現しました。

3. SSL証明書の自動発行
- 課題: SSL証明書の自動発行時に、DNS伝播の遅延により発行がすぐに反映されない問題がありました。リロードやクリックを繰り返しても状況は変わりませんでした。
- 解決: 時間が経過する（最大で24時間程度）ことで、DNSの伝播・自動SSL証明書発行がされ、問題は解消されました。
- 注意点：ただし、実際にLLMがサイトを読めた後でもエラーになるケースを複数回起こったため切り分けは困難な場合もあり。

LLM学習対象化の制御

Webサイト運営者として、LLMにコンテンツを見せたい場合と見せたくない場合があるでしょう。ここでは、それぞれのケースでの対策を解説します。
（実際に学習対象になったかどうかの確認は時間がかかるはずなので本記事では理論のみ記載）

LLMに見せたい場合
- robots.txtでの明示的な許可: クローラーに対してサイト全体の、または特定のパスへのアクセスを許可します。これがLLMがコンテンツを見つけるための基本的な指示になります。
- 整理されたHTML/URL構造: LLMがコンテンツの構造を理解しやすいように、セマンティックなHTMLと論理的なURL構造を心がけます。
- コンテンツの質: 専門性や信頼性の高い、質の良いコンテンツを提供することが最も重要です。
- llms.txtによる将来的なAI最適化の準備: llms.txtファイルを使用して、LLMに対する学習許可の意思を明示的に示します。これはrobots.txtを補完し、より細かな意図を伝えるためのものです。（注：現在は提案段階の標準で、主要LLMでの公式サポートはない）

LLMに見せたくない場合
- robots.txtでのBot明示的拒否: 特定のLLMクローラー、または全てのクローラーに対して、サイト全体や特定のパスへのアクセスを拒否します。
- 認証による制限: 会員制コンテンツなど、ログインが必要なページはLLMにクロールされません。
- 完全にJavaScriptなどの難読化（未検証）: JavaScriptを極度に利用した難読化されたコンテンツは、クロールが困難になる可能性があります。（ただし、これは未検証であり、現代のクローラーはJavaScriptの解析能力が高いため、確実な方法ではありません。）

学習を促進したい場合の設定例

robots.txt設定例:

User-agent: GPTBot Allow: /
User-agent: ClaudeBot Allow: /
User-agent: Google-Extended Allow: /
User-agent:  Allow: /

llms.txt で詳細ガイダンス提供 （例：学習許可の旨、クレジット表示の要請、引用のルールなどを記述）

学習を防止したい場合の設定例

robots.txt設定例:

User-agent: GPTBot Disallow: /
User-agent: ClaudeBot Disallow: /
User-agent: Google-Extended Disallow: /
User-agent:  Disallow: /

各ページに noindex メタタグ: <meta name="robots" content="noindex"> （検索エンジンやLLMにそのページをインデックスさせない）

今回の検証から得られた発見

今回の検証から、LLMとWebサイトの関係性について以下の重要な知見が得られました。
- 現代のLLMは進化している: 多様なホスティング形態やCMS技術に柔軟に対応し、多くのWebサイトをクロールできる能力を持っています。
- robots.txtの重要性: LLMへのアクセスを制御する上で、robots.txtが最も確実で標準的な手段であることが改めて確認されました。
- ハイブリッド構成の有効性: 静的ホスティングとCMSを組み合わせたハイブリッド構成でも、技術的な問題なくLLMからアクセス可能であることが分かりました。
- LLMへの「意図の明示」: llms.txtを利用して、LLMにコンテンツの学習許可や拒否の意思を明確に伝えることも検討はしておくと良いが実効性は今後要確認。
- AI時代への対応: LLMへの適切な対応は、これからのSEO（検索エンジン最適化）だけでなく、GEO（Generative Engine Optimization：生成AI最適化）といった新しい概念にもつながると考えられます。

まとめ

今回の実証検証により、以下の点が明確になりました。
- 現代のLLMは想像以上に多様なWebサイト技術にアクセス可能。（ただし、そのアクセス能力や結果はLLMによって異なる場合あり）
- 技術的な制約よりも、サイト運営者の意図的な設定による制御が重要。
- 適切な設計を行うことで、AIとの関係性を戦略的にコントロールすることが可能。
- ブラウザからのアクセスは問題なくても、LLMからのアクセスでは200でアクセス可能を確認した後に500エラーなどが発生する場合があったので確認時はそれも念頭に。
AI時代のWeb戦略として、「学習される前提」での情報設計と「制御可能な公開方針」の両立が、今後ますます重要になってきていると強く感じています。

検証データについて

本記事は実際のアクセステスト結果に基づいて記述しています。

免責

本記事は特定の時点での特定のサービスを用いた検証結果であり、その内容の正確性や網羅性、特定の状況への適用可能性について、いかなる責任も負いません。
 また、本記事の執筆プロセスにはAIの活用が含まれますが、記載内容の最終的な妥当性や適用性については、利用者の判断と責任においてご活用ください。

---
URL: https://cyber-secure.tech/insights/ai-regulation-risk-2025-06-30
Title: AIをめぐる制度とリスク管理の今（2025.06.30）
Last-Modified: 2025-06-30

AIにまつわる背景

AI技術は急速に進化し、私たちの社会や仕事に深く浸透しています。

こうした技術の利活用が進む一方で、AIに関わるリスク管理・倫理・制度対応もまた、同時に進化し続けています。

日本でもAIに関する法律「人工知能関連技術の研究開発及び活用の推進に関する法律」（AI推進法）が公布されましたのでこのタイミングで少しAIに関する規制やフレームワークなどをまとめてみました。

本稿では、2025年6月時点での主要なガイドライン・規制体系や、実務者が押さえておくべきAIガバナンスとAIセキュリティの基本構造を整理します。（AIの発展は急速ですので、同様に規定類も早い動きがあると予測しています）

AIセキュリティとは？

AIセキュリティとは、AIシステムとその利用環境を様々な脅威から保護し、安全かつ倫理的に運用するための包括的な取り組みを指します。対象には、モデル自体・学習データ・API連携・出力内容など多岐にわたります。

各種ガイドラインと規制の構造

日本国内の主なガイドライン

AI事業者ガイドライン（経産省・総務省）

「人間中心」「透明性」「安全性」「アカウンタビリティ」「教育」「プライバシー保護」等を掲げる共通指針 
 リビングドキュメントとして継続的に更新中

生成AIリスク対策ガイドブック（α版）［デジタル庁］

公共分野における生成AIの4つの典型ユースケース（チャットボット、要約、検索補助、コード生成）を想定 → 統合予定の包括的ガイドラインの先行ドキュメント

AI推進法（2025年5月成立・6月公布）

基本理念に「人間の尊厳」「多様性と包摂性」「持続可能性」を明記 → 日本初のAI分野特化法として罰則なしの推進型アプローチを採用

国際的フレームワーク・規格

OECD AI原則（G20共通基盤）

包摂的な成長／人間中心の価値／透明性と説明責任／頑健性・セキュリティ・安全性／アカウンタビリティの5原則

ISO/IEC 42001（AI専用マネジメントシステム規格）

ISO/IEC 27001（ISMS）と類似の構造を持つAI専用のマネジメントシステム規格として、AIに固有のガバナンス要素を導入

NIST AI RMF（米国NISTによるAIリスク管理枠組み）

GOVERN / MAP / MEASURE / MANAGE の4層構造でAIリスクを整理

EU AI Act（世界初のAI法）
- 許容不可（社会的スコアリングなど）
- 高リスク（法執行・雇用など）
- 限定リスク（チャットボット）
- 最小リスク（ゲーム等）
- GPAI規制（2025年8月から段階的に適用） - ChatGPTなどの汎用目的AI向け

セキュリティ関連知識体系
- MITRE ATLAS→ MITRE ATT&CKのAI版、AIシステムへの攻撃手法やリスクパターンを体系化
- OWASP Top 10 for LLMs→ 機密情報漏洩／プロンプトインジェクション／データポイズニング／偽情報生成／リソース枯渇など、LLM固有の脅威を整理

説明責任とガバナンスの中核：3つのキーワード

透明性（Transparency）
- 目的・機能・制限事項・アルゴリズム概要などを開示
- ステークホルダーごとに適切な情報提供が求められる

説明可能性（Explainability）
- 技術的説明（内部ロジック）
- 利用者向け説明（非技術者でも理解できる）
- 法的説明（規制当局への適合）

説明責任（Accountability）
- 組織としてのガバナンス体制確立
- モニタリング・文書化・監査可能性の担保
- 継続的なリスク管理と是正措置の運用

まとめ：戦略と制度の包括的な対策

AIガバナンスとAIセキュリティは、もはや「技術者だけの話」ではなく、経営・法務・現場実装すべてが関与すべきテーマです。

2025年6月時点で必要とされるのは：
- 各種ガイドライン・法規制の意図を理解し、現場に落とし込む力
- 技術的リスクと組織的リスクを統合的に捉える視点
- 透明性・説明責任・ガバナンスを意識した設計と運用
それぞれの組織が、自らの立場から何をすべきかを再確認しAIの健全な利活用とリスクコントロールを両立する取り組みが求められています。

お問い合わせ

AI活用や制度対応に関するご相談・講演依頼など、内容に応じて丁寧に対応させていただきます。

まずはお気軽にご連絡ください。

お問い合わせはこちら

---
URL: https://cyber-secure.tech/en/insights/ai-regulation-risk-2025-06-30
Title: AI Regulation and Risk Management: The Current Landscape (2025)
Last-Modified: 2025-06-30

Background on AI

AI technology is evolving rapidly and permeating our society and work. While adoption accelerates, risk management, ethics, and regulatory compliance for AI continue to evolve in parallel. With Japan's enactment of a law on AI ("Act on Promotion of Research, Development, and Utilization of AI-Related Technologies" — the AI Promotion Act), this is a timely opportunity to summarize AI-related regulations and frameworks.

This article organizes the major guidelines, regulatory frameworks, and fundamental structures of AI governance and AI security that practitioners should understand as of June 2025. (Given the rapid pace of AI development, regulations are expected to move equally fast.)

What Is AI Security?

AI security refers to comprehensive efforts to protect AI systems and their operating environments from various threats, ensuring safe and ethical operation. This encompasses the models themselves, training data, API integrations, output content, and more.

Guidelines and Regulatory Structures

Japan's Major Guidelines
- AI Business Operator Guidelines (METI/MIC): Common principles including "human-centered," "transparency," "safety," "accountability," "education," and "privacy protection." Continuously updated as a living document.
- Generative AI Risk Countermeasures Guidebook (alpha) [Digital Agency]: Covers four typical use cases for generative AI in the public sector (chatbots, summarization, search assistance, code generation). A precursor document to planned comprehensive guidelines.
- AI Promotion Act (enacted May 2025, promulgated June): Enshrines "human dignity," "diversity and inclusivity," and "sustainability" as basic principles. Japan's first AI-specific law, adopting a promotion-oriented approach without penalties.

International Frameworks and Standards
- OECD AI Principles (G20 common foundation): Five principles — inclusive growth, human-centered values, transparency and accountability, robustness/security/safety, and accountability.
- ISO/IEC 42001: An AI-specific management system standard with a structure similar to ISO/IEC 27001 (ISMS), introducing AI-specific governance elements.
- NIST AI RMF: A four-layer structure (GOVERN / MAP / MEASURE / MANAGE) for organizing AI risk.
- EU AI Act (world's first AI law): Risk categories from unacceptable (social scoring) through high-risk (law enforcement, employment), limited risk (chatbots), to minimal risk (games, etc.). GPAI regulations phased in from August 2025, covering general-purpose AI like ChatGPT.

Security Knowledge Bases
- MITRE ATLAS: The AI version of MITRE ATT&CK, systematizing attack techniques and risk patterns targeting AI systems.
- OWASP Top 10 for LLMs: Organizing LLM-specific threats including confidential information leakage, prompt injection, data poisoning, misinformation generation, and resource exhaustion.

Core Keywords for Accountability and Governance

Transparency: Disclosing purpose, functionality, limitations, and algorithmic overviews. Appropriate information must be provided for each stakeholder group.

Explainability: Technical explanations (internal logic), user-facing explanations (understandable by non-technical audiences), and legal explanations (regulatory compliance).

Accountability: Establishing organizational governance structures, ensuring monitoring, documentation, and auditability, and operating continuous risk management and corrective measures.

Conclusion: Comprehensive Strategic and Institutional Measures

AI governance and AI security are no longer "just for engineers" — they are themes that management, legal, and field implementation must all engage with. As of June 2025, what is needed includes:
- The ability to understand the intent behind guidelines and regulations and translate them into practice
- A perspective that integrates technical and organizational risk
- Design and operations that are conscious of transparency, accountability, and governance

Each organization must reaffirm what it should do from its own position, pursuing both healthy AI utilization and risk control.

Inquiries

For consultations regarding AI adoption, regulatory compliance, or speaking engagements, please contact us (/en/contact).

---
URL: https://cyber-secure.tech/en/insights/university-lecture-security-ai-2025-06-16
Title: University Lecture Report: Information Security and AI
Last-Modified: 2025-06-16

University Lecture Report: Information Security and AI (2025.06.16)

I delivered a guest lecture at the Faculty of Science and Technology, Keio University, on the theme of "The Importance and Practice of Information Security." This was a continuation from the previous year, made possible through personal connections, and provided a valuable opportunity to convey the intersection of security, privacy, and AI to students who will shape the next generation.

Key Topics
- Fundamental concepts of information security (the CIA triad, etc.)
- Real-world security operations and role division (technology, monitoring, analysis, incident response, etc.)
- Lessons from ransomware cases: Management and ethical decision-making frameworks
- The intersection of AI evolution and security (zero trust, responding to AI threats)
- Using SageMaker as a case study: "Explainable AI (XAI)" and international trends in transparency and accountability
- Security certifications and career development (CISSP, CEH, RISS, etc.)

Student Response: Change and Learning

This year, the heightened interest in "AI" was particularly striking. The majority of Q&A was about generative AI and AI risks, and I could see that students were actively using ChatGPT while simultaneously approaching it with a healthy skepticism.

Meanwhile, perspectives on security varied among individuals, with differences such as:
- Optimistic view: "If you know the methods, you can prevent it"
- Practical, cautious view: "Reality isn't that simple"

Recognizing these differences, I was reminded once again that security education is not merely about conveying knowledge — its essence lies in forming the ability to think: "How do I perceive risk, and how do I make decisions?"

Reflections from the Lecture

Fields such as security, privacy, and AI ethics are relevant to everyone, regardless of whether they are in the sciences or humanities. Through this lecture, I felt that I was able to create an opportunity for students who had thought "this has nothing to do with me" to begin thinking of it as something personally relevant.

Going forward, I want to continue serving as a bridge between the field and academia through activities that connect practice with education.

Inquiries & Speaking Requests

I welcome inquiries about lectures, training, and seminar engagements for universities, high schools, and companies. Please feel free to contact us (/en/contact).

---
URL: https://cyber-secure.tech/insights/university-lecture-security-ai-2025-06-16
Title: 大学講義レポート：情報セキュリティとAI（2025.06.16）
Last-Modified: 2025-06-16

はじめに

慶應義塾大学 理工学部にて「情報セキュリティの重要性と実践」というテーマで1コマの講義をゲスト講師として行ってきました。この講義は昨年に続きご縁を通じて担当させていただいたもので、次世代を担う学生の皆さんに、セキュリティとプライバシー、そしてAIとの交差点を伝える貴重な機会となりました。

主なトピック
- 情報セキュリティの基本概念（CIAの3要素など）
- 実際のセキュリティ業務とその役割分担（技術・監視・分析・インシデント対応など）
- ランサムウェア事例に学ぶ経営と倫理の判断軸
- AIの進化とセキュリティの交差点（ゼロトラスト、AI脅威への対応）
- SageMakerなどを題材にした「説明可能なAI（XAI）」と透明性・説明責任の国際動向
- セキュリティ資格とキャリアの築き方（CISSP・CEH・登録セキスペ等）

学生の反応：変化と学び

特に今年は「AI」への関心が顕著に高まっていたのが印象的でした。

質疑応答の大半が生成AIやAIリスクに関するもので、学生たちが実際にChatGPTを使いこなし、同時に懐疑心をもって向き合っている姿が見受けられました。
一方で、セキュリティに対する捉え方は人それぞれで、次のような違いもありました：
- 「やり方を知っていれば防げる」と考える楽観的な視点
- 「現実は甘くない」と理解する実践的・慎重な視点
こうした差を踏まえ、セキュリティ教育は単なる知識の伝達ではなく、「リスクをどう受け止め、どう判断するか」という思考の形成が本質だと、改めて実感しました。

講義を通じて感じたこと

セキュリティ・プライバシー・AI倫理といった分野は、理系／文系を問わず、全ての人に関わる領域です。

この講義では、「自分には関係ない」と思っていた学生が自分事として考えはじめるきっかけを作れたように感じました。

今後もこのような実務と教育をつなぐ活動を通じて、現場とアカデミアのギャップを埋める橋渡し役を続けていきたいと思います。

ご相談・講演依頼

大学・高校・企業向けの講義・研修・セミナー登壇のご相談も承っております。

お気軽にこちらよりご連絡ください。

---
URL: https://cyber-secure.tech/insights/cyber-privacy-ai-strategy-2025-01-19
Title: サイバーセキュリティ・プライバシー・AIガバナンスの勘所：守りと信頼構築の未来（2025.01.19）
Last-Modified: 2025-01-19

はじめに：リスクと倫理が交差する時代へ

現代社会では、サイバーセキュリティ、プライバシー、AIガバナンスの重要性がかつてないほど高まっています。

デジタル技術の進化により、新たなリスクや倫理的課題が日々顕在化しており、これらを包括的に理解することが求められています。

本記事では、これらの分野を横断的に捉えた「勘所」を整理し、実務や戦略にどう活かすべきかを解説します。

1. サイバーセキュリティの進化：信頼の基盤を守る

◆ 脅威の多様化と高度化

ランサムウェア、サプライチェーン攻撃、AIによるサイバー攻撃など、手口は日々進化しています。

「防ぐ」から「備える・対応する」へのシフトが求められています。

◆ 可視化とゼロトラストの重要性

リスク対応の基本は“可視化”：ネットワーク、クラウド、認証の弱点を把握し対応する力が不可欠です。

ゼロトラストモデル：すべてのアクセスを「検証する」前提で構築し、内部不正や侵入リスクを最小化します。

2. プライバシー：データ時代の信頼を築く

◆ プライバシーは“規制”から“競争力”へ

個人データは企業の資産であり、透明性と説明責任を果たす組織こそが信頼を得る時代です。

◆ 法制度の進化と対応の実践

GDPRや改正個人情報保護法など、各国のプライバシー規制が高度化・多様化

データ最小化／説明責任／プライバシー・バイ・デザインが実装の鍵となります

◆ プライバシー・バイ・デザイン

システム設計段階からプライバシー保護を組み込むことで、信頼と法的コンプライアンスの両立を実現できます。

3. AIガバナンス：技術の倫理と責任を追求する

◆ 信頼できるAIとは何か？

公平性／説明可能性／透明性：社会受容と法令遵守の両立が求められます

EUのAI Actのように、法制度も“リスクベースでの分類と対策”を求めています

◆ AIセキュリティとリスク

バイアスの排除：不公平な判断を防ぐモデル設計と検証プロセスが必要

説明可能性：内部の判断理由を外部に説明できる仕組みづくり

データポイズニングや敵対的サンプル（GAN）：AIそのものが攻撃対象にもなります

4. 統合的アプローチで未来を守る

セキュリティ、プライバシー、AIガバナンスは相互に関連し合う課題領域です。分断された対策ではなく、統合的アプローチが不可欠です。

具体的な実践アプローチ
- リスクの全体像を見える化し、部門を横断した体制構築
- 国内外規制との調和を取りながら、技術革新を追求
- 透明性・説明責任・データ最小化を中心に据えた戦略立案

まとめ：信頼を価値に変える組織へ

セキュリティ、プライバシー、AIガバナンスはもはや“守り”の話だけではありません。

組織の競争力と社会的信頼の中核を担う存在として、これらの実装が強く問われています。

今後も本サイトでは、実務に活かせる具体的視点から、最新の動向と解説をお届けしていきます。

この機会に、自社や自分自身の取り組みを見直すヒントとしていただければ幸いです。

ご相談・支援依頼はこちらから
- 「プライバシー・セキュリティ体制をどう整えるべきか？」
- 「AI活用に関する説明責任やリスク対応は足りているか？」
など、初回無料でのご相談・診断を承っております。

お気軽にこちらよりご連絡ください。

---
URL: https://cyber-secure.tech/en/insights/cyber-privacy-ai-strategy-2025-01-19
Title: Cybersecurity, Privacy, and AI Governance: Building Defense and Trust for the Future
Last-Modified: 2025-01-19

Introduction: An Era Where Risk and Ethics Intersect

In today's society, the importance of cybersecurity, privacy, and AI governance has never been greater. As digital technology evolves, new risks and ethical challenges emerge daily, and a comprehensive understanding of these domains is essential. This article organizes the key considerations across these fields and explains how to apply them to practice and strategy.

1. The Evolution of Cybersecurity: Protecting the Foundation of Trust

Diversifying and Advancing Threats

From ransomware to supply chain attacks and AI-powered cyber attacks, tactics evolve daily. A shift from "prevention" to "preparedness and response" is required.

The Importance of Visibility and Zero Trust

The foundation of risk management is visibility: the ability to identify and address weaknesses in networks, cloud environments, and authentication. The zero trust model builds on the premise that every access is verified, minimizing risks from insider threats and intrusions.

2. Privacy: Building Trust in the Data Age

Privacy Shifts from "Regulation" to "Competitive Advantage"

Personal data is a corporate asset, and the era belongs to organizations that demonstrate transparency and accountability.

Evolving Legal Frameworks and Practical Compliance

Privacy regulations worldwide — including GDPR and Japan's amended Act on the Protection of Personal Information — are becoming more sophisticated and diverse. Data minimization, accountability, and Privacy by Design are the keys to implementation.

Privacy by Design

By embedding privacy protections from the system design stage, organizations can achieve both trust and legal compliance.

3. AI Governance: Pursuing Ethics and Responsibility in Technology

What Is Trustworthy AI?

Fairness, explainability, and transparency: both social acceptance and legal compliance are required. As with the EU AI Act, legal frameworks are also demanding "risk-based classification and countermeasures."

AI Security and Risk
- Bias elimination: Model design and verification processes to prevent unfair decisions
- Explainability: Building mechanisms that can explain internal reasoning to external parties
- Data poisoning and adversarial samples (GANs): AI itself can become a target of attack

4. An Integrated Approach to Protecting the Future

Security, privacy, and AI governance are interrelated challenge domains. Rather than fragmented measures, an integrated approach is essential.

Practical Approaches
- Visualize the full risk landscape and build cross-departmental structures
- Pursue technological innovation while harmonizing with domestic and international regulations
- Formulate strategies centered on transparency, accountability, and data minimization

Conclusion: Toward Organizations That Transform Trust into Value

Security, privacy, and AI governance are no longer just about "defense." As core pillars of organizational competitiveness and social trust, their implementation is urgently demanded. We will continue to deliver the latest trends and analysis from practical perspectives through this site.

We hope this serves as a starting point for reassessing your organization's and your own initiatives.

Inquiries & Support

For questions such as "How should we structure our privacy and security framework?" or "Is our accountability and risk management for AI adequate?" — we offer initial consultations free of charge. Please feel free to contact us (/en/contact).

---
URL: https://cyber-secure.tech/en/insights/eu-institution-report-privacy-ai-2024-09-10
Title: European Institution Visit Report: Privacy, AI, and Policy Formation on the Ground
Last-Modified: 2024-09-10

Introduction

In summer 2024, as part of fieldwork in privacy, AI governance, and security, I visited a number of major institutions across Europe.

The aim was to deepen my understanding of "the atmosphere on the ground" and the policy-formation process — things that cannot be fully grasped from reading legal interpretation alone. I conducted both exterior visits to several institutions and reservation-based interior tours.

Visit Records (August–September 2024)

NATO Headquarters (exterior)

Impression: While I was unable to enter the building itself, the imposing atmosphere on site conveyed the sense of mission and presence of an organization at the core of international security. As an institution at the front line of responses to security and threats, it is one I will continue to watch.

European Parliament

Location: Parlamentarium and related facilities

Content: Through exhibits on its historical background, I gained a sense of the EU's legislative process and its emphasis on transparency.

The design of the space lets you take a bird's-eye view of how policy decisions are constructed through exhibits and historical materials, which made the link between the ideal of European integration and the realities of policy formation tangible.

I was also able to ask questions directly about open points on the AI Act — a valuable experience.

EDPB / EDPS (exterior)

Location: The building housing the EDPB and EDPS (exterior only)

Impression: Although I could not enter, the very fact that the central organizations responsible for the operation and supervision of the GDPR are co-located conveys the strength of the EU's integrated data protection regime. As I would come to feel later, the physical positioning of these institutions relative to each other carries meaning that you only sense by being there.

Standing in front of the building stirs an imagination of "what is being done inside" that you cannot get from text alone.

European Commission

Location: The Berlaymont building

Impression: I visited the exterior of the headquarters where the AI Act and GDPR drafts are written. The building itself is a symbolic presence, and the atmosphere of the "command center" leading EU-wide policy formation came through palpably.

The Council of the European Union

Location: The Europa building

Impression: Located across from the European Commission, this is the body where decisions of major importance — such as the final approval of the AI Act — take place. Being on site made the weight of that role concrete.

Content: I joined a reservation-based interior tour. I was guided through the layout of the meeting rooms, the seating rules for delegations from each member state, and the hall lined with the flags of the EU member states, with explanations of the multi-layered structure of decision-making, including the working parties.

Reflection: The orderliness of the venue and the meticulousness of the protocol struck me as a space that symbolizes the weight of the deliberations and the practical force of the institutions. The way EU thought is built into the structure of the building — the "design philosophy" supporting the institutions, which the exterior alone cannot convey — could be appreciated through the on-site explanations.

Court of Justice of the European Union (CJEU)

Location: The CJEU in Luxembourg (exterior)

Impression: I knew in advance that this is the venue where well-known judicial decisions are handed down, but actually visiting it impressed upon me — far more strongly than reading about it ever could — the gravity of the place where the front line of legal judgment unfolds.
The adjacent park also displays texts representing various strands of EU thinking, and I felt the cultural distance from Japan.

Note: I should have planned more carefully. Because of my hotel arrangements I visited on a Monday and was unable to enter the building. Individual visitors can attend plenary hearings on Tuesday, Wednesday, and Thursday, the days the court is in session. (Group visits appear to be handled differently.)

Summary: Understanding Institutions Through Space and Experience

What I felt most strongly through this visit is that understanding institutions and policies requires an on-the-ground sensibility and a grasp of the underlying values that can never be captured by literature or institutional commentary alone.

The structure of the buildings, the placement of the exhibitions, the protocols, the conduct of the people working there — all of these eloquently speak to the culture and philosophy that underpin the institutions themselves.

In particular, I came away with the following insights:
- In the EU, institutions are designed as a single integrated whole encompassing not just statutes and rules, but also "operations" and "symbolism."
- From exhibitions and spaces down to the very composition of the buildings, efforts to make transparency and accountability visible are thoroughgoing, and I felt this contributes to building trust in the institutions themselves.

The historical background and approach to institutional design are fundamentally different from Japan.

For example, in the EU, idealistic values such as human rights and freedom are placed at the core of institutions, and institutions function as the means by which those ideals are made concrete.

In Japan, by contrast, institutions are often built as "tools for solving practical problems," and the difference between the two lies less in structure than in the "source of the thinking."

What I saw on the ground was a city where multinational, multicultural people intersect on a daily basis, and the institutional attempt to support that.

That said, I personally also felt the balance and tensions that come with it, and the question of how institutions harmonize societal diversity is one I want to continue watching.

Through approximately one month on site, the greatest takeaway was that my perspective on institutions and policy expanded beyond "structure and statutes" to include the points of connection with the society and culture that lie behind them.

Practical Support and Speaking Engagements

The content of this visit translates into practical support in the following forms:
- Support for GDPR and AI Act compliance posture
- Risk assessment design informed by international legal trends
- Lectures and training (universities and corporations)

If you are interested, please reach out via the contact form.

This article represents the personal views of the author based on information available as of September 2024, and does not represent the views of any affiliated or related organization.

---
URL: https://cyber-secure.tech/insights/eu-institution-report-privacy-ai-2024-09-10
Title: 欧州機関訪問記：プライバシー・AI・政策形成の現場から（2024.09.10）
Last-Modified: 2024-09-10

はじめに

2024年夏、プライバシー・AIガバナンス・セキュリティ分野の調査の一環として、欧州各地の主要機関を訪問しました。

法制度の解釈だけでは得られない“現場の空気感”や政策形成プロセスへの理解を深めることを目的に、複数機関の外観見学や予約制の内部見学を実施しています。

訪問記録（2024年8月〜9月）

NATO本部（外観）

印象：建物内部には入れなかったものの、現地の重厚な雰囲気から国際的安全保障の中核組織としての使命感と存在感を実感しました。セキュリティや脅威への取り組みの最前線を担う存在として、今後も注視すべき組織です。

European Parliament

場所：Parlamentariumおよび関連施設

内容：歴史的背景に関する展示を通じ、EUの立法プロセスと透明性に触れました。

政策決定がどのように構築されていくか、展示・歴史資料を通して俯瞰できる設計になっており、欧州統合の理念と現実の政策形成との結びつきを理解できました。

AI Actに関する不明点に関して直接問い合わせるなど、貴重な体験も得られました。

EDPB／EDPS（外観）

場所：EDPB・EDPSの入居ビル（外観のみ）

印象：建物内部には入れなかったものの、GDPRの運用や監督を担う中枢組織が同居していること自体に、EUの一体的なデータ保護体制の強さを感じました。後ほどわかるのですが各施設の位置関係も含めて実際に行ってみると感じるものがありました。

文字情報で見るだけでは実感できない、「この建物で何が行われているか」の想像力をかき立てられます。

European Commission

場所：Berlaymont（ベルレモンビル）

印象：AI ActやGDPRの草案が起草される本部の建物外観を見学。このビル自体が象徴的存在であり、EU全体の政策形成をリードする「司令塔」の雰囲気がひしひしと伝わってきました。

The Council of the European Union

場所：Europaビルディング

印象：隣接するEuropean Commissionの向かいに位置し、AI Actの最終決定など重要な政策形成が行われる会議体であることを実感。

内容：予約制で内部見学を実施。会議室配置や各国代表の座席ルール、EU加盟国の旗が並ぶホールの見学を行いワーキングパーティを含む意思決定の多層構造に関する説明を受けました。

所感：会場の整然さ・プロトコルの緻密さにより、議論の重みと制度の実効性を象徴する空間と感じられました。ビルの構造にEUの思想が入っている点や、外観だけでは伝わらない制度を支える“設計思想”を実際の現場での説明を通じて得ることができました。

欧州連合司法裁判所（CJEU）

場所：ルクセンブルクのCJEU（外観）

印象：有名な方的判断が行われる場であることは事前に知っていましたが、実際に訪問するとやはり書物で読むだけでは得られない法的判断の最前線が繰り広げられる場の重厚さを強く感じました。
また、横にある公園に様々なEUの考え方が書かれており日本との文化の違いを感じました。

所管：きちんと調べて計画的に行くべきでしたが、ホテルの関係から月曜日に訪問したため内部に入ることはできませんでした。個人訪問者は、火・水・木曜の開廷日に本会議傍聴が可能なようです。（グループは別の扱いもあるようでした。）

まとめ： “空間と体験” を通じた制度の理解

今回の訪問を通じて強く感じたのは、制度や政策を理解するには、文献や制度解説だけでは決して掴みきれない“現場の肌感”や“価値観の根底”があるということです。

建物の構造や展示の配置、プロトコル、そこで働く人々の振る舞い――それらすべてが、制度そのものを支える文化や思想を雄弁に物語っていました。

特に、以下のような気づきがありました：
- EUにおいては、制度は条文や規則だけでなく、“運用”と“象徴性”を一体のものとして設計されている
- 展示や空間、建物の構成に至るまで、透明性と説明責任を可視化する工夫が徹底されており、それが制度への信頼形成にもつながっていると感じました。
日本とはまったく異なる歴史的背景と制度設計のアプローチがある

たとえばEUでは、人権や自由といった理念的価値が制度の根幹に据えられており、制度は理念を具体化する手段として機能している印象です。

一方、日本では制度が“実務的課題の解決手段”として構築されているケースが多く、両者の違いは構造よりも「発想の源」にあると感じました。

現地で目にしたのは、多国籍・多文化的な人々が日常的に交錯する都市の姿と、制度によってそれを支える試み

ただし、個人的にはそのバランスや緊張感も肌で感じる部分があり、制度が社会の多様性をどう調和させるのかという視点は、今後も継続して注目したいところです。

実際に1ヶ月ほどの滞在を通じて、制度や政策を見る視野が「構造や条文」だけでなく、その背後にある社会や文化との接続点にまで広がったことが、今回最大の収穫でした。

実務支援・登壇のご相談

今回の訪問内容は、以下のような形で実務支援に活かせます：
- GDPR・AI Actの体制整備支援
- 国際法動向を踏まえたリスクアセスメント設計
- 講演・研修（大学／企業）での実務支援
ご希望の方はこちらよりご連絡ください。

---
# Last generated: 2026-05-31