高木浩光＠自宅の日記(2025-12)

2025年12月06日

■ Digital Omnibus, Scope and Relevance: Are We Fighting the Wrong Battle?

In a previous post on the leaked “Digital Omnibus” draft, I played with the idea hidden in noyb’s name: None of Your Business – in other words, irrelevant. My point was that the GDPR already contains, in plain sight, a principle that should be at the core of the debate but is almost never mentioned: Article 5(1)(c)’s demand that data be adequate, relevant and limited to what is necessary in relation to a purpose. The real question is not how much “personal data” the law can cover in the abstract, but which data are any controller entitled to take into account for a given decision.

Since then, the Digital Omnibus proposal has been published, and noyb has issued a long report criticising it. The public debate has largely been framed as a familiar clash: on one side, a Commission accused of “watering down” the GDPR by narrowing the definition of personal data and creating new exceptions for AI and research; on the other, civil-society actors defending a maximal scope for “personal data” and a strong version of data minimisation.

In this post I want to argue that this is the wrong axis of conflict. Both sides are fighting over how broad the law’s coverage should be, while largely ignoring what the law was actually designed to control. The Omnibus debate is being treated as a war over definitions, when it should be treated as an opportunity to recover the original focus of data protection: the fairness of decisions about individuals, and the prevention of their being made on the basis of irrelevant data.

To make that case, I will first say something about the “maximal scope” paradigm that dominates current criticism of the Omnibus. I will then turn to the research and AI provisions, explain why both the Commission and noyb mis-locate the risks, and finally suggest a different way of looking at scope – one that re-reads “processing of personal data” in line with its directive-era function.

1. The “Maximal Scope” Paradigm and Its Limits

1.1 How the Omnibus Debate Frames Article 4(1)

A central target of current criticism of the Digital Omnibus proposal is the suggested rewording of Article 4(1) GDPR, the definition of “personal data”. In noyb’s reading, the new text would introduce a strongly controller-relative element into identifiability: whether information is “personal data” would depend on the specific controller’s perspective, resources or reasonable efforts. Pseudonymised data held by actors who lack re-identification keys might therefore fall outside the definition for them, even if another actor could identify the same records.

For noyb, this is not just an unfortunate drafting choice but a constitutional problem. The reasoning, roughly, is as follows:

the Charter of Fundamental Rights protects the “protection of personal data”;
the Court of Justice has repeatedly read “personal data” and “processing” very broadly;
therefore, any legislative move that appears to reduce that scope is a direct threat to fundamental rights.

On this view, the definition of “personal data” in Directive 95/46/E.C., as interpreted in landmark CJEU judgments, has been effectively “constitutionalised” by Article 8 of the Charter. And what is “constitutionalised” is understood as the breadth of the definition: the more generously we interpret “any information relating to an identified or identifiable natural person”, the more robust the protection of Article 8 must be.

From this vantage point, the only safe strategy is to insist that almost any information that can, in some chain of events, be linked to an individual must be treated as “personal data”, and that almost any operation involving that information must be treated as “processing”. The Omnibus proposal is thereby cast as an attempt to introduce controller-relative “subjectivity” into what ought to remain an objective, all-encompassing definition – a move that would undermine legal certainty, fragment enforcement and invite a race to the bottom.

I will call this way of thinking the maximal scope paradigm: the belief that the primary way to protect fundamental rights is to push the conceptual reach of “personal data” and “processing” as far as possible and then defend that maximal line against any retreat. Different actors occupy this paradigm in different ways – NGOs like noyb, some authorities and parts of the academic debate – but what they share is the assumption that “more situations legally qualifying as processing of personal data” almost automatically means “more effective protection.”

1.2 The Original Target of Data Protection: Decisions, Not “Data as Such”

Historically, however, the normative focus of European data protection instruments has never been “data as such”. It has been the use of data in systems of decision-making: credit scoring, employment screening, social security adjudication, policing, risk assessment, and so on. The early data protection laws, as well as their international precursors, were motivated by concerns that automated or computer-supported decisions about individuals could be made in opaque ways, based on incomplete, irrelevant or biased information, compiled in powerful, centralised files.

This orientation is visible in two features that are often overlooked in current debates.

First, the concept of processing was originally tied to what one might call an informational pipeline: a systematic sequence of operations through which data are collected, stored, combined, analysed and used to support decisions or actions. It was this pipeline – and the risks it created for individuals subjected to it – that justified a set of procedural and substantive constraints. The inclusion of “collection”, “use”, “disclosure” and “erasure” in the definition was meant to capture the different stages of that pipeline, not to transform any isolated mention of a person’s name into “processing” in the full legal sense.

Secondly, the much-cited triad of “adequate, relevant and not excessive” was framed as a data quality principle for decision-making. Its function was to ensure that decisions affecting individuals are based on information that has a rational link to the purpose of the decision, that is sufficiently complete and accurate for that purpose, and that does not include extraneous or prejudicial details. The idea was not to minimise data in the abstract, but to constrain the informational basis of decisions so that they are fair, non-arbitrary and non-discriminatory.

If one keeps this decision-oriented perspective in view, the relation between scope and protection looks different. What matters is not primarily how many pieces of information fall under the label “personal data”, but which informational pipelines and which decision contexts are brought within the reach of data protection law. A conception of “processing” that indiscriminately covers everything from one-off journalistic mentions to complex, automated profiling systems may be rhetorically expansive, but it risks obscuring precisely those structural features – centralisation, automation, iterative use – that generated the need for a specific legal regime in the first place.

1.3 A Preview: Two Layers of Protection

From this angle, the maximal scope paradigm is problematic in two ways.

It is over-broad, in that it extends the full conceptual and doctrinal apparatus of “processing of personal data” to contexts where the characteristic risks of data protection law are only marginally present. Treating every isolated reference to an individual, every casual photograph, or every transient log entry as “processing” subject to the GDPR may be logically possible under a literal reading of “any information relating to…”, but it stretches the concept far beyond the original risk profile it was designed to address. In doing so, it invites either pervasive non-compliance in everyday life or the proliferation of exceptions and derogations, which in turn make the law more complex and less intelligible.

At the same time, it is under-protective where protection is most urgently needed. By focusing energy on defending the outer conceptual perimeter of “personal data”, it diverts attention from the internal structure of those processing operations that truly matter: large-scale profiling, scoring and decision-support systems. Here, the crucial questions are not whether some fragment of information can be said to “relate” to an individual in the abstract, but whether the overall pipeline of processing is structured in such a way that decisions about individuals are based on adequate and relevant data, subject to meaningful contestation, and constrained by clear prohibitions on certain kinds of inferences.

Put differently, insistence on an ever-expanding notion of “personal data” risks functioning as a substitute for the harder work of identifying, and regulating, those decision contexts that require heightened protection. It can make it politically easier to denounce any perceived narrowing of scope – such as controller-relative identifiability in Article 4(1) – without having to say very much about which kinds of processing the fundamental right to data protection actually targets, and why.

To get out of this dead end, we need to recall that data protection law has always worked on two layers at once:

a decision layer, which governs how data are used in concrete decisions about individuals, and where “adequate, relevant and limited to what is necessary” should be understood as a genuine relevance requirement; and
a flow layer, which governs how data can move between contexts – purpose limitation, restrictions on re-use and onward disclosure – in order to prevent future decisions from being made on data that have no rational link to their purpose.

The rest of this post will unpack this two-layer structure and show how it helps to reframe the Omnibus debates about scientific research, AI and personal data definitions.

2. Scientific Research and AI: Data Minimisation without Decision Context

2.1 How the Omnibus and noyb Frame Scientific Research

A second focal point of the Omnibus debate is the proposed new definition of “scientific research” in Article 4(38) and the accompanying changes to purpose limitation and information duties, notably Article 13(5). The Commission’s draft defines scientific research, in essence, as “any research” that “can also support innovation”, supplemented by a long list of criteria referring to growth of society’s “knowledge and wellbeing”, adherence to “ethical standards in the relevant research area”, and similar elements.

noyb’s report offers a sharp and, in many respects, justified critique of this approach. It points out that:

the core term “research” is left so broad that it could cover almost anything, from “sifting through a library” or “using Google Search” to watching rats in a laboratory;
the phrase “any research which can also support innovation” extends the scope to mere possibilities (“can”) and by-products (“also”), so that virtually any data-driven activity in the name of innovation could qualify;
the requirement that research must be able to “support innovation” risks excluding areas of academic work not aimed at innovation in the economic or technological sense; and
references to “growth of society’s general knowledge and wellbeing” and to compliance with “ethical standards” are so indeterminate that they effectively outsource the definition of a Charter-limiting concept to private or sectoral ethics codes.

On this basis, noyb argues that the proposed definition, combined with an expanded framework for research exemptions, amounts to a “blanket allowance of further processing for a broadly and ill-defined ‘research purpose’”, which would likely fail the Charter’s requirements of necessity and proportionality. The Commission appears, in this reading, to be sacrificing the Article 7 and 8 rights on the altar of an amorphous “innovation” agenda.

At first glance, this critique appears squarely aligned with a rights-protective stance. Yet its internal logic again rests on two familiar premises: first, that the core of data protection is data minimisation as a direct emanation of Articles 7 and 8 and Article 52(1), and second, that the main threat posed by an overbroad research definition is the erosion of this minimisation and of purpose limitation as such. The questions of which types of research, and which decision contexts, ought to fall under stricter scrutiny remain largely implicit.

2.2 Research without Decisions vs Research Feeding Decisions

A decision-oriented perspective – one that takes seriously the role of adequacy and relevance in decision-making – suggests a different way to cut the problem.

On the one hand, there are forms of research that do not themselves feed into concrete decisions about identifiable individuals. Classic statistical and scientific uses of data, where the outputs are aggregate patterns, coefficients or models describing populations, may raise important issues of ethics, distributive justice and epistemic bias. But in terms of data protection, their risk profile is largely mediated by what happens after research: whether and how the resulting insights are embedded into operational decision systems.

On the other hand, there are forms of research that are structurally wired into treatment decisions: credit risk models developed on customer databases, hiring algorithms trained on past applicants, insurance pricing models, fraud detection tools. Here, the line between “research” and “operation” is thin. The same structured datasets used to develop the models are used, or readily usable, to support consequential decisions about individuals.

In this second family, what matters for data protection is not that “research” in the abstract uses more data than strictly necessary, but that the resulting decision systems may operate on data that are not relevant to the decision purpose. The core risk is arbitrary or discriminatory treatment: music taste influencing credit limits, social media activity affecting hiring, neighbourhood proxies standing in for ethnicity in insurance pricing. These are precisely the kinds of problems the adequacy and relevance requirement was originally meant to prevent.

From this angle, the Omnibus proposal’s changes to Article 4(38) and 13(5) are problematic, but not primarily because they offend an abstract ideal of data minimisation. They are problematic because they:

blur the distinction between research that merely generates statistical insight and research that is structurally embedded in decision pipelines; and
loosen purpose limitation and transparency duties in a way that weakens what I will later call the flow layer: the set of rules that restrict how data can move between contexts in order to prevent their use in irrelevant or discriminatory decisions.

noyb’s critique rightly attacks the vagueness of the definition and the risk of “innovation” being used as a carte blanche for further processing. But by casting the issue mainly in terms of Charter-compliant data minimisation, it misses the opportunity to ask the decisive question: which research-generated datasets are likely to flow into decision contexts, and how should their re-use be constrained to prevent irrelevant or discriminatory decision-making? This is the perspective I developed in my earlier post on the Omnibus debate, where I argued that both the Commission and noyb tend to overlook the GDPR’s explicit relevance requirement in Article 5(1)(c).

2.3 AI and Special Categories: Two Activities Confused under Article 9(2)(k) and (5)

The same pattern recurs, in sharper form, in the Omnibus proposal for Article 9(2)(k) and (5), dealing with AI and special categories of data. The draft introduces a new derogation for “processing in the context of the development and operation of an AI system … or an AI model”, accompanied by a paragraph 5 that requires controllers to implement “appropriate organisational and technical measures” to avoid the processing of special categories in training, testing and validation, and to remove such data where identified, or at least to prevent them from influencing outputs or being disclosed if removal would require disproportionate effort. The proposed recital 33 expressly frames this as a derogation from the Article 9(1) prohibition “in order not to disproportionately hinder the development and operation of AI”.

noyb criticises this structure on familiar grounds. It argues that AI is precisely the kind of opaque, large-scale processing that the data protection principles were originally designed to constrain; carving out a new derogation for AI development and operation is therefore backward-looking and threatens to hollow out the very safeguards that were written with such systems in mind. It also points out the loose drafting (“in the context of”, “appropriate measures”, “disproportionate effort”) and the risk that the derogation becomes a general permission for AI developers to retain special categories so long as they can claim to have implemented some minimisation efforts.

Again, this line of attack is understandable, but it presupposes that “AI development” is a unitary activity and that the relevant Charter risk can be captured by the volume and sensitivity of data processed. The actual situation is more complex.

As I argued in that earlier blog post, the label “AI development” currently covers two fundamentally different activities:

Treatment AI, such as credit scoring, hiring and insurance models, trains on genuine systematic datasets: customer or candidate databases that are prototypical “personal data” in the sense of data protection law. Here, database-oriented requirements make structural sense: minimise unnecessary special categories in training sets, remove them where inappropriately included, protect the sensitive training data against disclosure or misuse.
Generative AI training on public web text, by contrast, operates on scattered fragments of already public information to extract statistical patterns. It does not create systematic individual records; the resulting models do not, in normal operation, contain addressable records of specific persons’ sensitive characteristics. The main risks lie not in disclosure of special categories about identified individuals, but in the amplification of biases and stereotypes in generated content.

For the second family, Article 9(5)’s requirements are simply mis-specified. Instructing controllers to “remove” special categories from a corpus of heterogeneous web pages assumes a database-like structure that does not exist: what exactly is to be removed – sentences, paragraphs, entire documents? The “where possible” qualifier acknowledges the impracticality without providing a coherent standard. The language about preventing “disclosure” of special categories presupposes a context in which disclosure means revealing specific individuals’ sensitive data from a controlled database, not producing new text in which health or religion are mentioned in the abstract.

By lumping these structurally different activities together under a single derogation, the Omnibus proposal repeats the conceptual conflation already visible in the personal data definition. At the same time, and more importantly from a decision-oriented viewpoint, it misplaces regulatory attention:

Generative AI training on scattered public text, which normatively should not be treated as personal data processing at all because it never constructs systematic datasets suitable for decisions about individuals, becomes the direct target of impractical, database-oriented requirements.
Treatment AI operation, where structured datasets are used to make consequential decisions about individuals, receives relatively little targeted attention. Article 88c recognises AI operation as a legitimate interest, but provides no mechanism to enforce the relevance requirement of Article 5(1)(c) in this context. Irrelevant characteristics such as music preferences, social media activity or religious affiliation may thus be factored into decisions under the banner of “legitimate interest”, subject only to an individual right to object.

In short, both the Omnibus proposal and much of its criticism, including noyb’s, focus on how much and what kind of data AI systems may process, while leaving largely untouched the question whether the data used in AI-supported decisions are relevant to the decision purpose and how to prevent cross-context re-use of data in ways that generate arbitrary or discriminatory outcomes. That is precisely the gap that a relevance-based reading of Article 5(1)(c) is meant to fill.

2.4 So What Should Happen to the Research and AI Exceptions?

At this point the obvious question is: if both the Commission and noyb are framing the problem in the wrong way, what would a better treatment of research and AI actually look like? It seems clear that one political driver of both the new research definition and the AI derogation in Article 9(2)(k) – and of the attempt to redefine personal data – is the fear that, under the current reading of “processing of personal data”, even web-scale AI training and other large-scale analytics are automatically sucked into the full GDPR regime.

My answer is essentially the same as in my earlier post on the leaked Omnibus draft, but extended to the new definition and AI proposals.

Keep the existing statistical/research framework for the learning phase.
Europe already has a coherent way to deal with large-scale analysis that does not itself feed into decisions about individuals: the combination of
the “compatibility” rule for statistical and scientific purposes in Article 5(1)(b) GDPR; and
the older Council of Europe framework on statistical processing, which allows restrictions of individual rights as long as no decisions or measures concerning individuals are taken on the basis of the statistical results.

AI training belongs here. Training a model on large datasets is, in substance, statistical processing. In this phase there is, by definition, no concrete decision purpose yet, so it makes little sense to apply a relevance test at the level of the model or its inputs. The adequacy and relevance requirement is a constraint on the informational basis of decisions, not on the structure of models in the abstract. The core protected interest is not offended simply because a learning algorithm has “seen” certain variables; it is offended when those variables are actually used as part of a decision pipeline about individuals.

Draw a hard line at the operational, decision-making phase.
Once a trained model is used to support credit decisions, hiring decisions, insurance pricing, fraud detection and so on, we are no longer in the realm of “mere statistics”. We are in the realm of treatment AI, where the adequacy and relevance requirement must bite: every category of data that actually feeds into the decision pipeline must have a rational link to the decision purpose.

This distinction is crucial. A model may internally contain parameters influenced by many features, including features that would be irrelevant if used explicitly at decision time. What matters for data protection is which data are in fact taken into account when deciding about a person – which variables are read, combined and acted upon in the operational system. The legal architecture should therefore be very simple:

learning / training = statistical or research processing, covered by existing rules for such purposes, on the strict condition that the outputs are not used directly to decide about individuals;
operation = decision-making, subject to full data-quality scrutiny, including a serious enforcement of “adequate, relevant and not excessive” under Article 5(1)(c) with respect to the inputs actually used in the decision.
No special AI derogation is needed – and a broad one would be harmful.
If we treat AI training as statistical processing and AI operation as ordinary (but highly consequential) decision-making, there is no need for a new, AI-specific derogation in Article 9(2)(k) or elsewhere. On the contrary, a blanket derogation “for AI development and operation” risks doing exactly what I criticised in my previous post: it invites controllers to invoke “AI” as a magic keyword to justify both phases at once, while never asking the simple question at the operational phase: are the data we actually use in these AI-supported decisions relevant to the decision purpose?
Special categories do not need an AI-only regime either.
For the learning phase, the right question is not “how can we purge every trace of special categories from web-scale training corpora?”, but “how do we make sure that training corpora used for statistical purposes are not casually re-purposed into decision systems where special categories – direct or inferred – would be irrelevant to the decision purpose?”.

For the operation phase, if relevance is properly enforced, the distinction between directly revealed and inferred sensitive data becomes less important: both are ruled out wherever they are “none of your business” in light of the decision purpose. The problem, as I argued in the earlier post, is that we are currently trying to slim down Article 9 without first building the enforcement muscle around relevance at the decision layer.

In other words, instead of inventing AI-specific exceptions and research-specific shortcuts, we should put AI training back where it belongs – under the existing statistical/research framework – and concentrate regulatory energy on AI operation, where the relevance requirement finally has to be taken seriously at the point where decisions are made.

3. Decision Governance and Flow Governance: Re-reading “Processing of Personal Data”

The discussion so far already suggests that data protection operates on two interlocking layers:

decision governance, where the law constrains how data are used to make or support decisions about individuals; and
flow governance, where the law constrains how data can move between contexts, in order to prevent future misuse in irrelevant or discriminatory decisions.

We can now make this structure more explicit and ask how the Omnibus proposals affect each layer.

3.1 Two Complementary Layers of Protection

From a functional perspective, EU data protection law operates on two distinct but interdependent layers.

First, there is direct governance of decisions. Whenever personal data are actually used to make or support decisions about individuals, data protection law requires that the informational basis of those decisions meets the traditional data-quality standard: the data must be adequate and relevant to the purpose of the decision and not excessive. In modern language, there must be a rational link between the data items used and the legitimate decision purpose. This is where the classic “adequate, relevant and not excessive” formula belongs: it is a constraint on how decisions are made, not an abstract call to minimise data.

Second, there is preventive governance of data flows. Purpose limitation, restrictions on further use and onward disclosure, and the construction of “data silos” are not mysterious relics of a bygone era of database regulation. They are ex ante tools designed to prevent future violations of adequacy and relevance. The empirical intuition is simple:

Once data start to flow into new contexts, the probability that they will be re-used in decisions for which they are not relevant rises sharply.

If a dataset collected for one clearly defined purpose can be repurposed, combined and traded without structural constraints, it is only a matter of time before some actor uses it as input for decisions to which the data have no rational connection – credit scoring based on music taste, insurance pricing based on social media activity, hiring decisions based on political affiliation, and so on.

Seen in this light, purpose limitation is not a decorative recital about fairness. It is the central legal mechanism through which the law tries to shape the future graph of data flows: to determine which data can realistically end up feeding which decision systems. The decision layer governs the content of decisions (adequacy and relevance); the flow layer governs the routes through which data can travel into decision contexts in the first place.

Any attempt to redraw the boundary of “personal data” therefore has two effects:

It changes which operations count as “processing” for the purpose of direct decision governance; and
It determines where the preventive flow-governance layer applies at all. Data that fall outside “personal data” are not just exempt from information duties; they are exempt from purpose limitation and onward-transfer constraints, even if they later feed into decision systems.

The risk of the Omnibus proposal on personal data definitions is best understood at this second level.

3.2 How a Relative Personal Data Definition Undermines Flow Governance

The Omnibus proposal does not invent the idea that personal-data status may depend on the means of a particular controller; it codifies the Court’s relative approach, especially as expressed in more recent case law. The core idea is that information counts as personal data for a controller only if that controller has means that are “reasonably likely to be used” to identify the individuals concerned. Pseudonymised datasets held by actors who lack re-identification keys might therefore fall outside the definition for them, even if another actor could identify the same records.

On its face, this move is presented as a technical solution to a real problem: without some relativisation of identifiability, any data that someone could link to a person risks being treated as personal data for everyone. But once we look at the two-layer structure, a different picture emerges.

Consider a stylised scenario. A company collects information on music preferences – whether customers prefer jazz, rock or classical – linked to stable internal identifiers. At the time of collection, it pseudonymises the data and declares that they are used purely for market research. Under a relative definition, the company might argue:

it does not hold the mapping from identifiers to real-world identities;
it has no present means reasonably likely to be used to identify individuals;
therefore, the dataset is not “personal data” for it.

If accepted, this position has a crucial consequence: purpose limitation never attaches to the dataset. The data have been collected and processed in structured form, but as long as they are treated as “non-personal” for that controller, the entire flow-governance layer of data protection simply does not apply.

Fast-forward several years. The company changes strategy and enters the credit-scoring market. It discovers that music preference correlates, in its dataset, with repayment history. It now has strong incentives to:

re-establish or acquire a linkage between identifiers and individuals; and
re-use the existing music-preference dataset as an input for credit decisions.

At that moment, the company will insist that it now has identification means and that the data now constitute personal data. But purpose limitation will be invoked too late. Because the data were originally classified as “non-personal”, there was no legal obligation to tie their collection and retention to a specific, limited set of purposes, or to treat later re-use for credit scoring as a purpose change requiring a fresh legal basis and renewed guarantees for the individuals concerned.

This is not an exotic edge case. It describes a systematic pattern of “purpose drift through claimed non-identification”:

At collection: claim non-personal status (no identification means), thereby avoiding purpose limitation and related constraints;
In the interim: enjoy maximal freedom to replicate, analyse and trade the dataset as “non-personal”;
At some later point, when a lucrative decision-application emerges: reclassify the data as personal and use them for consequential decisions, by which time the preventive layer has already failed.

The same logic applies not only to isolated companies, but to entire chains of actors. If upstream entities can treat rich, individual-level structured datasets as “non-personal” on the basis that they lack re-identification keys, those datasets can circulate freely until they reach actors who do have the means and incentives to link them to identified persons and embed them in decision systems. Purpose limitation was meant to constrain exactly such cross-context flows; a relative definition makes it easy to step outside its reach during the most critical stages of dissemination.

The Omnibus proposal’s empowerment of the Commission to designate certain categories of pseudonymised datasets as “non-personal” through implementing acts would exacerbate this risk. Once such a designation is made, entire classes of structured data can travel as if they were mere technical exhaust, while remaining perfectly suited for later reintegration into decision pipelines. What disappears is not only some marginal transparency duty; it is the ex ante requirement to ask, at each step of the flow, “what purposes justify moving these data into this next context?”

From a decision-and-flow-oriented perspective, then, the danger of the Omnibus redefinition is not primarily that it makes the GDPR less “broad” in an abstract sense. It is that it removes structured, decision-capable datasets from the preventive flow-governance layer at precisely the stages where that layer does its most important work.

At the same time, it is worth recalling that the GDPR already contains a gate in the form of its material scope clause. Article 2 confines the Regulation to the “processing of personal data”. The popular complaint that “the GDPR applies to everything” does not stem from the absence of such a gate, but from the way in which “processing” has gradually been flattened into “any handling of any information about a person” – including, in the political imagination, web crawling for AI training or other large-scale analytics. The Omnibus proposals take this perception of overbreadth at face value and try to cure it at the level of the definition of personal data itself. The maximal scope paradigm reacts from the opposite direction and defends the broadest possible reading of “personal data” and “processing”. What both moves have in common is that they leave the structural notion of processing untouched – and with it, the original idea that the material scope of the GDPR was meant to capture systematic, file-like processing pipelines, not every scattered mention of an individual.

3.3 A Decision-and-Flow-Oriented Scope Test

Against that background, if we take seriously both layers of protection, an alternative way of framing the scope question suggests itself. Rather than asking how far we can conceptually stretch the notions of “personal data” and “processing”, we should ask in which situations EU data protection law must, at a minimum, apply with full force across both layers.

A decision-and-flow-oriented test could be formulated, in preview, along these lines:

Systematic pipeline
There must be a systematic informational pipeline in the original sense of “processing”: a structured sequence of operations on data organised according to stable categories or formats, not merely isolated mentions or ad hoc exchanges. This is the threshold that distinguishes “data” from scattered “information” and captures what early data protection instruments were designed to regulate.
Decision context
The outputs of this pipeline are, or are reasonably likely to be, used in decision contexts that affect individuals’ legal or social position: credit, employment, insurance, social benefits, access to services, law enforcement, and comparable domains. Here the decision layer kicks in: Article 5(1)(c) must be interpreted and enforced as a genuine relevance requirement, demanding a rational link between each category of processed data and the stated decision purpose.
Cross-context flow risk
The data in the pipeline can realistically flow into other decision contexts in which they would not be relevant, unless purpose limitation and onward-transfer rules apply. Where such cross-context drift is structurally plausible – as in large-scale analytics, AI development and platform ecosystems – the flow layer should apply from the moment the data are collected in structured form, regardless of whether the controller currently claims to have identification means.

On this view, the problem with the Omnibus redefinition of personal data is not that it abandons an abstract ideal of maximal scope. The problem is that it allows controllers to step outside this three-part test at will by declaring, at collection time, that they lack identification means – even when they are building exactly the kind of structured datasets that can later be fed into consequential decision systems. Once those datasets are born outside the legal category of “personal data”, the law’s ex ante capacity to shape their future flows is crippled.

The same test also helps to separate, conceptually, different families of AI-related processing. Generative-AI training on scattered public text corpora may fail the first and third prongs: it does not create systematic, individual-addressable datasets, and its outputs are not naturally wired into decision contexts. By contrast, treatment AI – credit scoring, hiring algorithms, insurance pricing models – falls squarely within all three: it operates on structured records, directly supports decisions about individuals, and its datasets have obvious cross-context re-use potential.

3.4 Re-reading “Processing of Personal Data” in Light of the Directive’s History

This interpretive proposal is not a call to rewrite the text of Article 4(1) GDPR. It is a call to re-read the existing concepts of “processing of personal data” and “personal data” in light of their directive-era function.

Historically, the structural understanding of “processing” was not an accidental by-product of outdated “file” concepts. The Commission’s 1990 proposal still spoke the language of files, but when the Parliament insisted on replacing “file” by “processing of personal data”, this was not meant to abandon the structural requirement altogether. It was meant to capture file-like processing pipelines, including on-the-fly decision systems that reproduce the same risks without a literal, centralised file. The shift from “file” to “processing of personal data” thus extended the concept along a functional line, rather than dissolving it into “any handling of any information”.

Some judgments – particularly in borderline cases – can be read as stretching the concept for specific factual constellations without turning “processing” into “any handling of any information” as a general rule. Where genuine tensions remain, they suggest that the Omnibus is premature in constitutionalising a maximalist scope at precisely the moment when the underlying concept still requires careful doctrinal clarification.

4. Conclusion: Not a War over Scope, but a Chance to Recover What Data Protection Was For

If you only read the open letters and press releases around the Digital Omnibus, it looks like a familiar drama. On one side, the Commission, accused of “watering down the GDPR” by narrowing the definition of personal data and creating new derogations for AI and research. On the other side, noyb and others, defending a maximal scope for personal data and a strong version of data minimisation.

My argument in this post, building on my earlier analysis, is that this is the wrong axis of conflict. Both sides are fighting over how broad the law’s coverage should be, while largely ignoring what the law was actually designed to control. From the 1970s onward, European data protection law was not about “data” in the abstract. It was about systems of decision-making: the pipelines through which structured data are collected, organised and used to allocate jobs, credit, insurance, social benefits and other advantages and burdens.

Seen from that angle, the core of the GDPR is not an abstract horror of “too much data”, but a pair of linked questions: which data may legitimately be taken into account in decisions about individuals, and how should we prevent data from flowing into decision contexts where they have no rational link to the purpose? That is what the data-quality principle and purpose limitation were originally built to address.

At this point, two natural questions may arise.

The first is that this may still sound like data minimisation by another name. After all, Article 5(1)(c) GDPR now literally speaks of data being “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed”, and Directive 95/46/EC already spoke of “adequate, relevant and not excessive”. Hasn’t the law always been about minimising data?

My answer is that, historically, this triad was framed as a data-quality principle for decisions, not as a free-floating command to collect “as little data as possible”. “Not excessive” – and its later rephrasing as “limited to what is necessary” – was embedded in a standard that also demanded adequacy and relevance for a given decision purpose. Supervisory guidance often glosses “adequate” as “sufficient to properly fulfil your stated purpose”. But “sufficient” sometimes means more data, not less: more complete income information to avoid arbitrary denials of credit, more context to avoid misinterpreting a single data point, more nuance to prevent crude profiling. A pure minimisation reading, which treats “less data” as always better from a fundamental-rights perspective, erases this ambivalence and collapses adequacy and relevance into a one-dimensional “volume” metric. In that light, rebadging Article 5(1)(c) as the data minimisation principle is itself part of the problem: it obscures the original focus on relevance and sufficiency for decisions, and makes it easier to overlook situations where better protection in fact requires better – not thinner – data.

A second, closely related question is whether all this ultimately collapses into a call to strengthen Article 22 GDPR on automated decision-making. The recent battles around Article 22 are, in a way, a symptom of the same misframing. Because we forget that the data-quality principle already governs the informational basis of all decisions that take personal data into account, there is a tendency to load every concern about profiling and AI onto the narrow category of “solely automated” decisions in Article 22. One camp therefore demands an ever broader Article 22, hoping it will cure problems that actually belong in the general regime of Article 5(1)(c). Another camp concludes that Article 22 is an overreach that stigmatises even proper profiling that respects adequacy and relevance, and pushes to hollow it out or abolish it – a mood that is not entirely absent from the Omnibus debates.

What both sides risk forgetting is that Article 22 is a lex specialis for a very small subset of cases. The basic standard I have tried to reconstruct here is more general and more basic: it applies whenever personal data are used in decision-making at all, regardless of the mix of automation and human involvement. That standard lives primarily in Article 5(1)(c) and the surrounding data-quality and purpose-limitation provisions, not in Article 22. Strengthening Article 22 cannot substitute for taking the relevance requirement seriously across the board. Weakening Article 22 does not make decision systems benign if we continue to ignore adequacy and relevance at the decision layer and to relax flow governance so that irrelevant data can silently seep into consequential decisions.

Against that background, the real promise and danger of the Digital Omnibus become clearer. The promise is that the current controversy could have forced us to reopen the basic questions: what counts as “processing of personal data” in the structural sense? where do the characteristic risks of data protection actually arise? how should we distinguish statistical or learning phases from operational decision-making? The danger is that we instead constitutionalise a maximalist reading of scope at the very moment when the underlying concept of processing still needs careful doctrinal work – and, at the same time, quietly open back doors for exactly those structured datasets that most urgently require tight flow governance.

The alternative sketched in this post is modest in textual ambition but radical in effect. It does not call for rewriting Article 4(1); it calls for re-reading “processing of personal data” and Article 5(1)(c) in line with their directive-era function. It suggests that AI training should be treated as statistical processing under existing rules, and that the real regulatory energy should be directed at AI operation and other decision systems, where the adequacy and relevance requirement finally has to bite. And it suggests that both the Commission and its critics would do better to shift their attention from how far the legal concept of personal data can be stretched, to how the law governs the pipelines by which data flow into decisions. That, after all, was what data protection was for.

■ デジタル・オムニバス、スコープ、そして関連性──我々は間違った戦いをしているのではないか

本来であれば、学術論文の形で発表すべき（根拠となる文献をふんだんに引用して*1）ところであり、実際その執筆作業は一部進めているのだが、何ヶ月もかけて悠長にしていられる状況ではない。EUの政治は今まさに動いており、このままでは混迷を深めるばかりで、もはや今のEDPB・EDPSでは頼りになるとは期待しがたい*2。仮名化データを個人データとみなすかどうかは、GDPRの立法過程でも争点となったところだし、そもそも欧州評議会1997年勧告の段階で既に認識されていた課題である。CETS 108以来の「データ品質」原則が、GDPRの立法過程でドイツ的な誤訳を経た「データ最小化」原則へと捻じ曲げられ、それを当時の欧州理事会が辛うじて押し返していたことも、今となっては欧州でどれだけ共有されているのか心許ない。前回の投稿について思い切ってドイツのレジェンド教授にメールでお伝えしたところ、なんと、すぐに読んで頂けたようでお返事があり、称賛のお言葉とともに、わしはもう歳じゃから君がやりなさいとの励ましを頂いた。

そんなわけで、取り急ぎ大規模言語モデルの力を借りて、あちらの人たちに刺さる表現になるよう工夫して生成したのが上に掲載した英語ブログである。これは以下の手順で生成した。まず、前回の続きでClaudeに書かせていたのだが、イマイチあちらに刺さる感じに仕上がらなかったのでボツとし、ChatGPT（5.1）に一から書かせた。ChatGPTの調査力はかなり（特に8月のGPT-5以降）良く、ここ半年はChatGPTをメインに調査していたので、そのメモリー機能によってChatGPTは、私がどういう調査をしてどのような立場なのかを概ね把握しているようであり、何も言わなくても大筋の判断はできてしまうようだった。それでも材料が足りなかったので、ボツにしたClaude原稿（それは私の既発表論文群をソースにして生成されている）を読ませて観点を補充し、最終的にこちらから足りない要素を指摘して補完させ、完成に至った。

そのプロンプトを以下に開示しておく。完成版の日本語訳（Claudeによる翻訳）は最後に置いたので、結論から読みたい人は最後のターンまでスキップするとよい。

私：noybがレポートを出してきましたよ。これまで通りかな。 https://noyb.eu/sites/default/files/2025-12/noyb%20Digital%20Omnibus%20Report%20V1.pdf

ChatGPT：ざっと一通り目を通しましたが、「これまで通りのnoyb」という感じで、大枠のスタンスは完全に従来線ですね。

（略）

もし必要なら、あなたの立場（processing 概念やスコープ論）から見て「ここは使える／ここはずれている」という仕分けも、条文ごとにやっていきましょう。

私：おお、どこまで自動的にできるのかな？それをやってみてください。

ChatGPT：やってみました。
PDF 全体をざっとなめて、noyb が章立てしている 14 本の条文ごとのコメントを拾って、「あなたのいつもの立場（処理概念／スコープ論／決定指向モデル）」から見てどれくらいそのまま使えそうかをざっくり自動分類してみました。

記号はこんな感じで付けています：

◎：かなりそのまま使える（立場がかなり近い）
○：基本方向は同じだが、前提理論は違うので要フィルタ
△：一部の指摘だけつまみ食いならアリ。基本線はズレ気味
×：あなたのスコープ論と正面から衝突しそう

（略）

私：うーん、いや、「使える」というのは、逆方向で、noybがダメな批判をしているぞ本当はこっちだぞ！ということを言うのに使えるかを基準にしてほしいw。

ChatGPT：なるほど、「noybすごい！使える！」じゃなくて
「noybの批判がズレてる例として使えるかどうか」が基準ですねw 了解です。

ざっくり言うと、この Digital Omnibus レポートは「GDPR＝Charter 7/8条の最大限のスコープを死守する」という立場に振り切れていて、あなたの「決定指向＋スコープを整理する」路線から見ると、ツッコミどころの宝庫です。

以下、「こういう点で noyb がダメ、本当はこう考えるべきだ」という形で、論点ごとに“使い方”を書きます。

（略）

私：おお、よくわかってくれているね、素晴らしい。しかしここから欧州方面の一般読者に説得力のある論述を構成するのはなかなかにタフだと思う。しかしやらねばならぬし、チャンスだよなあ。

ChatGPT：そう、「ここから欧州読者を口説き落とす」のが本番ですよね。
でも、今のタイミングでそれをやるの、本当にチャンスだと思います。

とりあえず「どういうストーリーで書けば欧州方面に刺さるか」を、かなり具体的に組み立ててみます。

（略）

私：なるほどうまいなあ。ではそれをやってみてください。

ChatGPT：（略）

私：おお、上手ですね。その調子で続きまで書けちゃいますか？

ChatGPT：（略）

私：maximal scope paradigm、Maxだけにねw。このパートは答えを示さず終わっている感があるので、次と次を終えた後で解決策を示すのかな？

ChatGPT：（略）

私：セクション3はそんな感じで良さそうですが、セクション4の答えは弱いと思う。決定の適切性確保のための直接規制（原則遵守）だけではなく、不適切な決定を予防するための目的外の利用・提供の禁止がある。目的外利用が禁止されるのは一般的にデータが目的外に決定利用されれば元の目的とは異なって決定の目的に関連性のないデータとなる蓋然性が高いから。流通を制限するのも同じ理由から。今回のpersonal data定義変更はそこを直撃することを言った方がいい。この観点を中心に別途Claudeに書かせた原稿案があるのだけど、Omnibus提案の中身を正確に捉えきれていないなど先走った内容で失敗作になった（それで今ここで作り直している）んだけど、参考になる要素を拾ってみる？

ChatGPT：そうそう、まさにそこですよね。
「決定の適切性の直接規制」だけだと半分しか描けてなくて、目的外利用・提供禁止という「予防の層」が本丸のかなり大きい部分を占めている、というのは絶対に前面に出した方がいい。

（略）

別途Claudeに書かせた原稿案がある … 参考になる要素を拾ってみる？

ぜひやりたいです。
今こちらで組んだ 4章の骨格があるので、（略）

私：こちらがそのClaude原稿です。

ChatGPT：うん、このClaude原稿、めちゃくちゃ素材が詰まってますね。
「決定レイヤー」と「予防レイヤー（目的外利用・流通制限）」という話は、ほぼ全部ここから組み立てられそうです。

（略）

私：まずはいいでしょう。ではその調子でセクション3を書いてみてください。

ChatGPT：いきます、そのまま英語でセクション3を書きますね。（略）

私：OK、細かな問題がいくつかある。
・フローの話をセクション3でしれっと使っているけど、初出はセクション4だよね。作成した順と並べる順が逆転しているよ。
・「As the earlier draft argument reconstructed in Section 7 of my previous paper」とあるけどそれってさっきのClaudeのボツ原稿のことだよね。それは参照できないよ。
・「前回述べたように」のような記述が数箇所あるのは、すでに発表した前哨戦の私のブログのことを指しているのだと思うけど、それは望むところなのだけど、どんなブログだったか把握してる？以下のURLにあるので見ておいて。それを踏まえて、そこにリンクするつもりで書き方を調整したい。
https://takagi-hiromitsu.jp/diary/20251120.html

あとは、セクション4だけど、さっきの内容だと、まだ尻切れ感がある。結論セクションを追加するのかな？

ChatGPT：いいポイントの突き方してくるなあ…w
ご指摘3点、その通りなので、順番と書き方を整理し直します。

（略）

私：概ねそれで良さそうですが、「personal data 定義を flow-governance の観点から再設計」の具体的な中身はどうするのかな。定義を変更せずとも解釈でデータ保護指令の際の意義を再確認するという方向性がいいのではないかなあ。1990年の欧州委員会提案ではfile概念を用いていたけど欧州議会で「fileは古い」と言われて「processing of personal data」に置き換えた経緯がある。それは完全に構造要件を捨てたわけではなく、蓄積を伴わないオンザフライ決定を含める必要性が認識されていたからだと思うのよね。そこの根拠は論文（日本語だが）で発表済みだがそこを参照するほど深入りせずにサクッと断言してしまうのが吉かも。判例と矛盾すると一蹴される予感もするが、それも本当は判決を精査しないといけないと思うのよねえ。

ChatGPT：（略）

私：概ねいいですが、いくつか気になるところが以下です。
・これは論文ではなくブログポストなので、注はしっかり入れてないで割り切っていいです。ブログ用だからと表現を平易にする必要はありませんが、表記が矛盾しないように気をつけて。
・結論として、定義をどうするかの話は盛り込んだが、研究とAIの例外をどうするかが足りてないのでは？私の立場は要するに学習段階は統計目的として扱えばOKというものです。
・前哨戦の内容をやっぱり見ておいてもらった方が良さそうなので、印刷したPDFを置きます。これを既に読んだ読者向け（未読ならリンク先を見る想定）でうまく簡潔にできる部分があると思う。

ChatGPT：了解です、だいぶ全体像がクリアになりました。
前哨戦ブログもざっと把握しました（あの「None of Your Business＝irrelevant」ネタ、今回も美味しく使えますね）。

（略）

私：3.5のところ、惜しいのが、関連性が求められるのは決定段階でありモデル自体（モデルの入力）には求められないのであるということがうまく書けていない。
5.のところ、惜しいのは、「Within that framework, research and AI do not need ……」のところで、生成AIの方のトレーニングではfile的な処理ではないという話を書いてないこと。

ChatGPT：いいところ突いてきますね、その2点はちゃんと直した方がいいやつです。

（略）

私：OK、これであとは全体を生成してみることだけど、その前にちょっと検討。さっき添付したClaudeのボツ原稿では、クローリングに着目して、検索エンジンだって同じなのに問題にしてこなかったじゃないかという話から始めていて、それはそれでキャッチーな入り方だと思っていたのだけど、Google Spein判決の話が入ってきてややこしくなる上、今回のOmnibus提案はそこの部分についてさほど悪くはない案になっているようだから、正当な批判にならなかったと思ってボツにした。その評価は妥当だと思う？今回のバージョンをそこと比べるとどう評価できる？

ChatGPT：感覚として持ってた違和感、かなり正確だと思います。

（略）

私：OK、小ネタにするのはやめておきましょう。では、全体を生成してください。その際に、全体の表現の統一感を確認しながらでお願いします。canvasに出力できるのでしたっけ？

ChatGPT：できました。

（略）

私：OK、noybは答えを見つけようとはしていない（できないからかもしれないし、そうする立場でもないからかもしれないが）から、言えちゃう批判をしているだけなので、結果的にmaximal scope paradigmの一員になっているというところかな。もう一つは、欧州委員会のような定義を狭めようとする策というのは典型的に「体系的」processing限定をわかっていない人たちが疑問視するGDPRの定義の広すぎさ論であり、我々の論法は、それに対するカウンターであり、生成AIの学習段階での障害を回避するために定義までいじってきたのだろうという想定で批判しているので、そのこととの関係が今のドラフトでは見えにくくなっている気がしてきたが、どうか。

ChatGPT：そうそう、その整理でだいたいピタッと来てますね。

（略）

私：あ、新たな問題点に気づいた。「scope」の語だけども、定義のscopeのことを言っているのだろうけど、GDPRの規定では、material scopeとして現れる言葉で、そこがまさしく、processing of personal dataに限定すると規定している箇所なので、用語の混乱があるなあ。

ChatGPT：うわ、そのポイントに気づくのめちゃくちゃ鋭いです。
これはたしかに EU 法クラスタに読ませるならケアした方がいいやつですね。

（略）

私：ラベルは生かすのは同感として、しかし、Art.2のscopeとは別と注意書きを入れるのは上手くない（ややこしくなって読者はついてこない）と思うなあ。むしろ、欧州委員会側がmaterial scopeによる限定を無視しているだろ、という指摘を入れることによって、scope概念の交差を中盤か後ろあたりで拾うのはどうだろうか。

ChatGPT：なるほど、その発想いいですね。
「scope という言葉を冒頭で定義で潰す」のではなく、（略）

私：その件とさっきの欧州委員会側の「定義を狭めたい動機」の件を合わせて直すとして、加筆で済ますというよりも周辺の見直しも含めて全体を再検討してもいいよ。

ChatGPT：いいですね、「全体をもう一度組み直してもいい」という一言で、むしろ構造がきれいになりました。

いまやった主な調整はこんな感じです：

（略）

私：ブログ原稿を通して再読した。この内容だと、だいぶ早い段階で「それGDPR 22条を強化すべきという話だよね？」と思ってしまう読者がかなり多いと思う。上の方で単純に否定しても下まで読まないとわからないだろうから、上の方で何か入れて、下の方でそれとの違いを論じた方がいいと思われる。横道に逸れる感じではあるが、どこにどう入れるのがいいだろうか。

ChatGPT：そうそう、その「22条じゃないの？」という読みは、かなり早い段階で大勢の人が頭に浮かびそうなので、そこを先回りしておいた方がいいですね。

いま入れた修正はこんな方針です：

（略）

私：先ほど追加した22条のところ、冒頭で言うにはちょっと重いかなあ。まだそこの段階では「決定」の話をしているとは感じられないのでは？

ChatGPT：うん、それはその通りだと思います。
今の入れ方だと、

（略）

私：本当は脚注に書くような話なのよね（脚注は今回使わない）。なので確かに、22条パラグラフを上に移動すると思考があっちゃこっちゃ行ってしまうので、この辺に置いた方がいい。というところかなあ。改めて通して読んでみたけど、やっぱりこの場所でも異物感があるなあ。いっそ結論パートに移してはどうだろうか？

ChatGPT：うん、その感覚けっこうよくわかります。
3.1 の流れは「二層構造の提示 → それぞれの役割 → Omnibus でどこが壊れるか」に集中していて、22条はやっぱり「脚注ネタ」に近いので、そこに入るとどうしても異物感が出ますね。

（略）

私：OK、あと、結論パートはまとめだから必然かもしれないけどそれにしても同じ話の繰り返しだなあという重複感は感じていたところ。それに加えてもう一つ、改善の必要なポイントを思いついた。それは、全体を通して、データ品質原則がDPDまでの「adequate, relevant and not excessive」とGDPR以降の「adequate, relevant and limited (minimisation)」とが両方使われているので、混乱しそうでうです。noybがminimisation原理主義になっていると批判しながら、「ate, relevant and not excessive」と持ち正しても「同じものでは？」と思う人がいそう。それは仕方ないが、DPDからGDPRで変えられてしまったのだということを言っておきたいところ。それも合わせて結論パートをそういう疑問視への回収パートにすればいいのではないかな。

ChatGPT：うん、その2点（22条の位置と DPD→GDPR の文言変更）を結論パートで「回収する」方向はかなり良さそうです。

（略）

私：「反論」と書くより、「疑問が湧くかもしれない」的な言い回しの方がいいなあ。

ChatGPT：わかる、そのニュアンスの差はけっこう大きいですよね。「objection」って書くと、読者を敵に回してる感じがちょっと出る。

（略）

私：うーん、1点目は、「adequate」の意味について触れるといいのでは？ICOのガイダンスではsufficientと説明しているよね、これは量を増やすという意味なので、data minimisationというラベルは完全に矛盾しているのだけど、GDPR作った時にadequateもrelevantも意味を取り違えたのでは？という指摘ができる。2点目は、「Strengthening Article 22 may well be desirable」としているけど、むしろ、そこも誤解ゆえの争いになっているところで、自動決定じゃない通常決定も規制しているのがデータ品質原則だということを忘れているが故に問題を22条の強化でカバーしろと言う人たちがいる一方で、これはデータ品質原則に適合する正しいプロファイリングをも規制するものなので規制が不要だという勢力もいて今回のような案が出ているわけですよね。その辺をうまく言いたいな。

ChatGPT：いいポイントが2つきれいに刺さっているので、それをそのまま結論に反映させる形で書き換えてみました。

（略）

これで完成。これをClaudeで日本語訳させたのが以下である。

私：これは先ほどChatGPTに書かせた文章です。日本語訳を作成してもらいます。直訳調より読みやすさを優先してください。専門用語については統一をお願いしたい。まず要注意な用語を洗い出してください。先にその訳を決めましょう。

（略）

デジタル・オムニバス、スコープ、そして関連性──我々は間違った戦いをしているのではないか

以前の投稿で、デジタル・オムニバス草案のリークを取り上げた際、私はnoybという名前に隠された意味──None of Your Business、すなわち無関係──を手がかりに議論を展開した。私が言いたかったのは、GDPRには、本来この議論の中心に据えられるべき原則が明文で存在しているにもかかわらず、ほとんど言及されていないということだ。それは5条1項(c)が求める、データは目的との関係で「十分であり、関連性があり、必要なものに限定される」べきだという要件である。本当の問題は、法がどれだけ多くの「個人データ」を抽象的にカバーできるかではない。ある決定に際して、管理者がどのデータを考慮に入れることが許されるのか──これこそが問われるべき問いなのだ。

その後、デジタル・オムニバス提案が公表され、noybはこれを批判する長大なレポートを公開した。公の議論は、おなじみの対立構図として描かれている。一方には、個人データの定義を狭め、AIや研究のための新たな例外を設けることでGDPRを「骨抜きにしている」と非難される欧州委員会。他方には、「個人データ」の最大限のスコープと、データ最小化の強いバージョンを擁護する市民社会のアクターたち。

本稿で私が主張したいのは、これが間違った対立軸だということである。両陣営とも、法の射程をどこまで広げるべきかをめぐって争っているが、法が本来何をコントロールするために設計されたのかという点はほとんど無視されている。オムニバスをめぐる議論は、定義をめぐる戦争として扱われているが、本来はデータ保護の原点──個人に関する決定の公正さ、そして無関係なデータに基づく決定の防止──を取り戻す機会として扱われるべきなのだ。

この主張を展開するために、まずオムニバス批判を支配している「最大スコープ」パラダイムについて述べる。次に研究とAIに関する規定に目を向け、なぜ欧州委員会もnoybもリスクの所在を見誤っているのかを説明する。最後に、スコープについての別の見方──「個人データの処理」を指令時代の機能に即して読み直すアプローチ──を提案したい。

1. 「最大スコープ」パラダイムとその限界

1.1 オムニバス論争における4条1項の位置づけ

デジタル・オムニバス提案に対する現在の批判の中心的な標的は、GDPR 4条1項、すなわち「個人データ」の定義の改正案である。noybの読み方によれば、新しい条文は識別可能性に強く管理者相対的な要素を導入するものだという。すなわち、ある情報がpersonal dataであるかどうかは、当該管理者の視点、リソース、あるいは合理的な努力に依存することになる。再識別のための鍵を持たない主体が保有する仮名化データは、たとえ別の主体が同じレコードを識別できるとしても、その主体にとっては定義の外に落ちる可能性がある。

noybにとって、これは単なる起草上の不備ではなく、憲法上の問題である。その論理は概ね次のようなものだ。

EU基本権憲章は「個人データの保護」を保障している
EU司法裁判所はpersonal dataとprocessingを繰り返し広く解釈してきた
したがって、そのスコープを縮小するように見えるいかなる立法的措置も、基本権への直接的な脅威である

この見方によれば、データ保護指令におけるpersonal dataの定義は、EU司法裁判所の画期的判決を通じて解釈されてきたとおり、EU基本権憲章8条によって事実上「憲法化」されている。そして「憲法化」されたものは、その定義の広さとして理解される。「識別された又は識別可能な自然人に関するあらゆる情報」をより寛大に解釈すればするほど、8条の保護はより堅固になるはずだ、と。

この観点からすれば、唯一の安全な戦略は、何らかの事象の連鎖によって個人と結びつきうるほぼすべての情報をpersonal dataとして扱うべきだと主張し、その情報を含むほぼすべての操作をprocessingとして扱うべきだと主張することになる。オムニバス提案は、客観的で包括的であるべき定義に、管理者相対的な「主観性」を持ち込もうとする試みとして描かれる。それは法的安定性を損ない、執行を分断し、底辺への競争を招くものだ、と。

私はこのような考え方を最大スコープ・パラダイムと呼ぶことにする。基本権を保護する主要な方法は、personal dataとprocessingの概念的到達範囲を可能な限り押し広げ、その最大線をいかなる後退からも守ることだという信念である。このパラダイムには様々なアクターが様々な形で位置している──noybのようなNGO、一部の当局、そして学界の一部──しかし彼らが共有しているのは、「個人データの処理として法的に該当する状況が増える」ことがほぼ自動的に「より効果的な保護」を意味するという想定である。

1.2 データ保護の本来の標的：「データそのもの」ではなく「決定」

しかし歴史的に見れば、欧州のデータ保護法制の規範的焦点は「データそのもの」に向けられたことはなかった。それは意思決定システムにおけるデータの利用に向けられていた。信用スコアリング、雇用審査、社会保障の裁定、警察活動、リスク評価などである。初期のデータ保護法、およびその国際的な先行規範は、個人に関する自動化された、あるいはコンピュータ支援による決定が、不透明な方法で、不完全、無関係、あるいは偏った情報に基づいて、強力で中央集権的なファイルにまとめられた形で行われうることへの懸念を動機としていた。

この方向性は、現在の議論ではしばしば見過ごされている二つの特徴に見て取れる。

第一に、processingの概念は、本来、いわば情報パイプラインと結びついていた。データが収集され、保存され、結合され、分析され、決定や行為を支援するために使用される、という一連の体系的な操作のことである。一連の手続的・実体的制約を正当化したのは、このパイプライン──そしてそれにさらされる個人に対してパイプラインが生み出すリスク──であった。定義に「収集」「利用」「開示」「消去」が含まれていたのは、このパイプラインの各段階を捉えるためであり、ある人物の名前への孤立した言及をすべて完全な法的意味でのprocessingに変換するためではなかった。

第二に、よく引用される「十分であり、関連性があり、過度でない」という三要素は、意思決定のためのデータ品質原則として構成されていた。その機能は、個人に影響を及ぼす決定が、決定目的と合理的な関連を持つ情報に基づいて行われ、その目的にとって十分に完全かつ正確であり、無関係な詳細や偏見を含まないことを保証することであった。その趣旨は、データを抽象的に最小化することではなく、決定の情報的基盤を制約して、決定が公正で、恣意的でなく、差別的でないようにすることだった。

この決定志向の視点を念頭に置けば、スコープと保護の関係は違って見える。重要なのは、主として「個人データ」というラベルの下にどれだけ多くの情報が入るかではなく、どの情報パイプラインとどの決定文脈がデータ保護法の射程内に入るかである。一回限りのジャーナリスティックな言及から複雑な自動プロファイリングシステムまで、あらゆるものを無差別にカバーするprocessingの概念は、レトリックとしては拡張的かもしれないが、そもそも特別な法的レジームを必要とした構造的特徴──中央集権化、自動化、反復的使用──をまさに覆い隠してしまうリスクがある。

1.3 保護の二つの層──見取り図

この観点から見ると、最大スコープ・パラダイムは二つの点で問題がある。

それは過剰に広い。「個人データの処理」という概念的・教義的な装置一式を、データ保護法の特徴的なリスクがごくわずかしか存在しない文脈にまで拡張してしまう。個人へのあらゆる孤立した言及、あらゆる何気ない写真、あらゆる一時的なログエントリをGDPR上の「processing」として扱うことは、「…に関するあらゆる情報」という文言の字義通りの解釈として論理的には可能かもしれないが、それは概念を、本来対処すべきリスク・プロファイルをはるかに超えて拡張してしまう。そうすることで、日常生活における広範な遵守不能か、例外と適用除外の増殖を招き、後者は法をより複雑で理解しにくいものにする。

同時に、それは最も保護が切実に必要とされる場面では保護が不十分である。personal dataの概念的外縁を守ることにエネルギーを集中させることで、真に重要な処理操作──大規模プロファイリング、スコアリング、決定支援システム──の内部構造から注意をそらしてしまう。ここで決定的な問いは、ある情報の断片が抽象的に個人と「関連する」と言えるかどうかではなく、処理のパイプライン全体が、個人に関する決定が十分かつ関連性のあるデータに基づいて行われ、有意義な異議申立ての対象となり、一定の種類の推論に対する明確な禁止によって制約されるような形で構造化されているかどうかである。

言い換えれば、「個人データ」概念の際限のない拡張への固執は、より困難な作業──高度な保護を必要とする決定文脈を特定し規制すること──の代替物として機能するリスクがある。それは、データ保護の基本権が実際にどのような種類の処理を標的としているのか、そしてなぜなのかについてあまり語らなくても、4条1項における管理者相対的な識別可能性のようなスコープの縮小と見えるものを非難することを政治的に容易にしてしまう。

この袋小路から抜け出すためには、データ保護法が常に二つの層で同時に機能してきたことを思い出す必要がある。

決定層。個人に関する具体的な決定においてデータがどのように使用されるかを規律し、「十分であり、関連性があり、必要なものに限定される」は真正な関連性要件として理解されるべきである。
流通層。データが文脈間をどのように移動しうるかを規律する──目的制限、再利用と転送の制限──将来の決定が、その目的と合理的な関連を持たないデータに基づいて行われることを防ぐために。

本稿の残りでは、この二層構造を詳しく解きほぐし、それがオムニバスをめぐる科学研究、AI、およびpersonal dataの定義についての議論をどのように再構成するのに役立つかを示す。

2. 科学研究とAI：決定文脈なきデータ最小化

2.1 オムニバスとnoybが科学研究をどう捉えているか

オムニバス論争の第二の焦点は、4条38項で提案されている「科学研究」の新しい定義と、それに伴う目的制限と情報義務の変更、特に13条5項である。欧州委員会の草案は、科学研究を本質的に「イノベーションをも支援しうるあらゆる研究」と定義し、社会の「知識と福祉」の成長、「当該研究分野における倫理基準」の遵守、および類似の要素を参照する長いリストの基準を付け加えている。

noybのレポートは、このアプローチに対して鋭く、多くの点で正当な批判を展開している。それは次のように指摘する。p>

中核用語である「研究」があまりに広く放置されており、「図書館で資料を調べる」「Google検索を使う」から実験室でネズミを観察することまで、ほとんど何でもカバーしうる
「イノベーションをも支援しうるあらゆる研究」というフレーズは、スコープを単なる可能性（「しうる」）と副産物（「も」）にまで拡張しており、イノベーションの名の下に行われるほぼすべてのデータ駆動活動が該当しうる
研究が「イノベーションを支援しうる」という要件は、経済的・技術的意味でのイノベーションを目指さない学術研究領域を排除するリスクがある
「社会の一般的な知識と福祉の成長」や「倫理基準」の遵守への言及は不確定であり、憲章を制限する概念の定義を私的または分野別の倫理規範に事実上外部委託している

この分析に基づき、noybは、提案された定義は、研究適用除外の拡大された枠組みと組み合わさって、「広範かつ不明確に定義された『研究目的』のためのさらなる処理を一律に許容する」ことになり、憲章の必要性と比例性の要件を満たさない可能性が高いと主張する。この読み方によれば、欧州委員会は無定形の「イノベーション」アジェンダの祭壇に7条と8条の権利を犠牲として捧げているように見える。

一見すると、この批判は権利保護的な立場と完全に一致しているように見える。しかしその内部ロジックは、やはり二つのおなじみの前提に依拠している。第一に、データ保護の核心は、7条・8条および52条1項の直接的な発現としてのデータ最小化であるという前提。第二に、過度に広い研究定義がもたらす主要な脅威は、このデータ最小化と目的制限そのものの浸食であるという前提。どの種類の研究が、そしてどの決定文脈が、より厳格な審査の対象とされるべきかという問いは、ほとんど暗黙のままである。

2.2 決定を伴わない研究と決定に供される研究

決定志向の視点──意思決定における十分性と関連性の役割を真剣に受け止める視点──は、この問題を切り分ける別の方法を示唆する。

一方には、識別可能な個人に関する具体的な決定に直接供されない形態の研究がある。古典的な統計的・科学的データ利用、すなわち産出物が集団を記述する集計的パターン、係数、モデルであるような利用は、倫理、分配的正義、認識論的バイアスの重要な問題を提起しうる。しかしデータ保護の観点からは、そのリスク・プロファイルは主として研究の後に何が起こるかによって媒介される。すなわち、得られた知見が運用上の決定システムにどのように、どの程度組み込まれるかである。

他方には、処遇決定に構造的に接続されている形態の研究がある。顧客データベースで開発される信用リスクモデル、過去の応募者で訓練される採用アルゴリズム、保険価格モデル、不正検知ツールなどである。ここでは、「研究」と「運用」の境界は薄い。モデルを開発するために使用されるのと同じ構造化されたデータセットが、個人に関する重大な決定を支援するために使用される、あるいは容易に使用可能である。

この第二の類型において、データ保護にとって重要なのは、抽象的な「研究」が厳密に必要な以上のデータを使用することではなく、結果として生じる決定システムが決定目的と関連しないデータに基づいて運用されうることである。核心的なリスクは恣意的または差別的な処遇である。音楽の趣味が与信限度額に影響を与える、ソーシャルメディア活動が採用に影響する、近隣の代理変数が保険価格において民族性の代わりに使われる。これらはまさに、十分性と関連性の要件が本来防止するはずだった種類の問題である。

この観点からすれば、オムニバス提案の4条38項および13条5項の変更は問題があるが、それは主としてデータ最小化という抽象的な理想を侵害するからではない。それらが問題なのは、以下の理由による。

単に統計的知見を生成する研究と、決定パイプラインに構造的に組み込まれた研究との区別を曖昧にしている
後に流通層と呼ぶもの──無関係または差別的な決定におけるデータ利用を防ぐために、データが文脈間をどのように移動しうるかを制限するルールの集合──を弱める形で、目的制限と透明性義務を緩和している

noybの批判は、定義の曖昧さと「イノベーション」がさらなる処理の白紙委任として使われるリスクを正しく攻撃している。しかし、問題を主として憲章に適合するデータ最小化の観点から捉えることで、決定的な問いを発する機会を逃している。どの研究生成データセットが決定文脈に流入する可能性が高く、無関係または差別的な意思決定を防ぐためにその再利用はどのように制約されるべきか？これは、以前のオムニバス論争に関する投稿で私が展開した視点であり、そこで私は欧州委員会もnoybも5条1項(c)のGDPRの明示的な関連性要件を見落としがちだと主張した。

2.3 AIと特別カテゴリー：9条2項(k)および5項の下で混同された二つの活動

同じパターンが、AIと特別カテゴリーのデータを扱う9条2項(k)および5項に関するオムニバス提案において、より鮮明な形で繰り返されている。草案は「AIシステム…またはAIモデルの開発および運用の文脈における処理」のための新たな適用除外を導入し、5項では管理者に対し、訓練、テスト、検証において特別カテゴリーの処理を避けるための「適切な組織的・技術的措置」を講じ、特定された場合はそのようなデータを削除するか、削除に不均衡な努力を要する場合は少なくとも出力への影響や開示を防止することを求めている。提案された前文33は、これを「AIの開発と運用を不均衡に妨げないために」9条1項の禁止からの適用除外として明示的に位置づけている。

noybはこの構造をおなじみの論拠で批判している。AIはまさにデータ保護原則が本来制約するために設計された、不透明で大規模な処理の一種であり、AI開発・運用のための新たな適用除外を設けることは後ろ向きであり、そのようなシステムを念頭に置いて書かれたまさにその保障を骨抜きにする恐れがある、と。また、緩い起草（「の文脈における」「適切な措置」「不均衡な努力」）と、何らかの最小化努力を講じたと主張できる限りAI開発者が特別カテゴリーを保持することを一般的に許可することになるリスクも指摘している。

ここでも、この批判路線は理解できるが、それは「AI開発」が単一の活動であり、関連する憲章上のリスクは処理されるデータの量と機微性によって捕捉できるという前提に立っている。実際の状況はより複雑である。

以前のブログ投稿で私が主張したように、「AI開発」というラベルは現在、根本的に異なる二つの活動をカバーしている。

処遇AI、例えば信用スコアリング、採用、保険モデルは、真正な体系的データセット──データ保護法の意味でのプロトタイプ的な「個人データ」である顧客または候補者のデータベース──で訓練される。ここでは、データベース志向の要件が構造的に意味を持つ。訓練セットにおける不必要な特別カテゴリーを最小化し、不適切に含まれている場合は削除し、機微な訓練データを開示や悪用から保護する。
生成AIの公開ウェブテキストに対する訓練は、対照的に、すでに公開されている情報の散在する断片を処理して統計的パターンを抽出する。それは体系的な個人レコードを作成しない。結果として生じるモデルは、通常の運用において、特定の人物の機微な特性についてアドレス可能なレコードを含まない。主要なリスクは、識別された個人についての特別カテゴリーの開示ではなく、生成されたコンテンツにおけるバイアスやステレオタイプの増幅にある。

第二の類型について、9条5項の要件は単に的外れである。管理者に対し、異質なウェブページのコーパスから特別カテゴリーを「削除」するよう指示することは、存在しないデータベース的構造を前提としている。正確には何を削除すべきなのか──文、段落、文書全体か？「可能な場合」という修飾語は、首尾一貫した基準を提供することなく実行不可能性を認めている。特別カテゴリーの「開示」を防止するという文言は、開示が管理されたデータベースから特定の個人の機微データを明らかにすることを意味する文脈を前提としており、健康や宗教が抽象的に言及される新しいテキストを生成することではない。

これらの構造的に異なる活動を単一の適用除外の下にまとめることで、オムニバス提案はpersonal dataの定義においてすでに見られた概念的混同を繰り返している。同時に、決定志向の観点からより重要なことに、それは規制上の注意を誤った場所に向けている。

散在する公開テキストに対する生成AIの訓練は、個人に関する決定に適した体系的データセットを構築することがないため、規範的にはpersonal dataの処理として扱われるべきではないにもかかわらず、実行不可能なデータベース志向の要件の直接の標的となる。
処遇AIの運用──構造化されたデータセットを使用して個人に関する重大な決定を行う場面──は、比較的少ない的を絞った注目しか受けない。88c条はAI運用を正当な利益として認めているが、この文脈で5条1項(c)の関連性要件を執行する仕組みを提供していない。したがって、音楽の好み、ソーシャルメディア活動、宗教的所属といった無関係な特性が、「正当な利益」の旗印の下で決定に織り込まれうることになり、個人の異議申立権のみが制約となる。

要するに、オムニバス提案もその批判の多く（noybを含む）も、AIシステムがどれだけの、どのような種類のデータを処理しうるかに焦点を当て、AI支援決定に使用されるデータが決定目的と関連しているかどうか、そして恣意的または差別的な結果を生む形でのデータの文脈横断的再利用をどのように防ぐかという問いは、ほとんど手つかずのまま残している。これがまさに、5条1項(c)の関連性に基づく解釈が埋めるべきギャップなのである。

2.4 では、研究とAIの例外はどうあるべきか

この時点で明白な問いが浮かぶ。欧州委員会もnoybも問題を間違った形で捉えているなら、研究とAIのより良い扱いは実際にはどのようなものになるのか？ 新しい研究定義と9条2項(k)のAI適用除外──そしてpersonal dataを再定義しようとする試み──の両方に共通する政治的な動因の一つは、現在の「個人データの処理」の解釈の下では、ウェブスケールのAI訓練やその他の大規模分析さえもGDPRの完全なレジームに自動的に吸い込まれてしまうという恐れであることは明らかだろう。

私の答えは、リークされたオムニバス草案に関する以前の投稿と本質的に同じだが、新しい定義とAI提案にまで拡張される。

学習フェーズには既存の統計・研究の枠組みを維持する
欧州にはすでに、個人に関する決定にそれ自体が供されない大規模分析を扱う首尾一貫した方法がある。それは以下の組み合わせである。
GDPR 5条1項(b)における統計・科学目的のための「両立性」ルール
欧州評議会の統計処理に関する古い枠組み。これは、統計結果に基づいて個人に関する決定や措置が取られない限り、個人の権利の制限を認めている。

AI訓練はここに属する。大規模データセットでモデルを訓練することは、実質的に統計処理である。この段階では、定義上、まだ具体的な決定目的がないので、モデルやその入力のレベルで関連性テストを適用することにはあまり意味がない。十分性と関連性の要件は、決定の情報的基盤に対する制約であり、抽象的なモデルの構造に対する制約ではない。保護される核心的利益は、学習アルゴリズムが特定の変数を「見た」というだけで侵害されるのではない。それは、それらの変数が実際に個人に関する決定パイプラインの一部として使用されるときに侵害される。

運用、すなわち意思決定フェーズに明確な線を引く
訓練されたモデルが与信決定、採用決定、保険価格設定、不正検知などを支援するために使用されるようになれば、我々はもはや「単なる統計」の領域にはいない。処遇AIの領域にいるのであり、そこでは十分性と関連性の要件が効力を発揮しなければならない。決定パイプラインに実際に投入されるすべてのデータカテゴリーは、決定目的と合理的な関連を持たなければならない。

この区別は決定的に重要である。モデルは内部的に、決定時に明示的に使用されれば無関係となる特徴を含む多くの特徴に影響されたパラメータを含んでいるかもしれない。データ保護にとって重要なのは、ある人物について決定する際に実際にどのデータが考慮されるか──運用システムにおいてどの変数が読み取られ、結合され、行動の基礎とされるか──である。したがって、法的アーキテクチャは非常にシンプルであるべきだ。

学習・訓練＝統計または研究処理。そのような目的のための既存ルールでカバーされ、産出物が直接に個人について決定するために使用されないことを厳格な条件とする
運用＝意思決定。完全なデータ品質審査の対象となり、決定に実際に使用される入力に関して5条1項(c)の「十分であり、関連性があり、過度でない」の真摯な執行を含む
特別なAI適用除外は不要であり、広範なものは有害である
AI訓練を統計処理として、AI運用を通常の（しかし極めて重大な）意思決定として扱うなら、9条2項(k)その他における新たなAI固有の適用除外は必要ない。むしろ、「AI開発・運用のための」一律適用除外は、以前の投稿で私が批判したまさにそのことを招くリスクがある。管理者が「AI」をマジックワードとして援用し、両フェーズを同時に正当化することを可能にし、運用フェーズにおけるシンプルな問い──このAI支援決定に実際に使用するデータは、決定目的と関連しているか？──を問うことがなくなる。
特別カテゴリーもAI専用レジームを必要としない
学習フェーズについて、正しい問いは「ウェブスケールの訓練コーパスから特別カテゴリーのあらゆる痕跡をどのように除去できるか？」ではなく、「統計目的で使用される訓練コーパスが、特別カテゴリー──直接的であれ推論されたものであれ──が決定目的と無関係となる決定システムにカジュアルに転用されないようにするにはどうすればよいか？」である。

運用フェーズについて、関連性が適切に執行されれば、直接明らかにされた機微データと推論された機微データの区別はさほど重要ではなくなる。両方とも、決定目的に照らして「あなたには無関係」である場合には排除される。以前の投稿で私が主張したように、問題は、我々が決定層における関連性についての執行力をまず構築することなく、9条をスリム化しようとしていることである。

言い換えれば、AI固有の例外や研究固有のショートカットを発明する代わりに、AI訓練を本来の場所──既存の統計・研究の枠組み──に戻し、規制上のエネルギーを、関連性要件が決定がなされる時点でついに真剣に受け止められなければならないAI運用に集中させるべきなのである。

3. 決定ガバナンスと流通ガバナンス：「個人データの処理」を読み直す

ここまでの議論は、データ保護が相互に連関する二つの層で機能していることをすでに示唆している。

決定ガバナンス。個人に関する決定を行う、または支援するためにデータがどのように使用されるかを法が制約する。
流通ガバナンス。将来の無関係または差別的な決定における悪用を防ぐために、データが文脈間をどのように移動しうるかを法が制約する。

この構造をより明確にし、オムニバス提案が各層にどのように影響するかを問うことができる。

3.1 保護の二つの相補的な層

機能的な観点から見ると、EUのデータ保護法は二つの別個だが相互依存的な層で機能している。

第一に、決定の直接的ガバナンスがある。個人データが実際に個人に関する決定を行う、または支援するために使用される場合、データ保護法は、それらの決定の情報的基盤が伝統的なデータ品質基準を満たすことを要求する。データは決定の目的にとって十分であり関連性があり、過度であってはならない。現代の言葉で言えば、使用されるデータ項目と正当な決定目的との間に合理的な関連がなければならない。古典的な「十分であり、関連性があり、過度でない」という定式が属するのはここである。それは決定がどのように行われるかに対する制約であり、データを抽象的に最小化せよという呼びかけではない。

第二に、データ流通の予防的ガバナンスがある。目的制限、再利用と転送の制限、「データサイロ」の構築は、過ぎ去ったデータベース規制時代の不可解な遺物ではない。それらは十分性と関連性の将来の違反を防止するために設計された事前のツールである。経験的な直観はシンプルである。

データがいったん新しい文脈に流入し始めると、それが関連性のない決定に再利用される確率は急激に上昇する。

ある明確に定義された目的のために収集されたデータセットが、構造的制約なしに転用、結合、取引されうるなら、ある主体がそれを、データと合理的な関連のない決定への入力として使用するのは時間の問題である──音楽の趣味に基づく信用スコアリング、ソーシャルメディア活動に基づく保険価格設定、政治的所属に基づく採用決定など。

このように見れば、目的制限は公正さについての装飾的な前文ではない。それは、どのデータが現実的にどの決定システムに供されうるかというデータ流通の将来のグラフを法が形成しようとする中心的な法的メカニズムである。決定層は決定の内容（十分性と関連性）を規律し、流通層はデータがそもそも決定文脈にたどり着きうる経路を規律する。

したがって、「個人データ」の境界を引き直そうとする試みは二つの効果を持つ。

直接的な決定ガバナンスの目的でどの操作がprocessingとしてカウントされるかを変える
予防的な流通ガバナンス層がそもそもどこに適用されるかを決定する。personal dataの外に落ちるデータは、情報義務から免除されるだけではない。たとえ後に決定システムに供されるとしても、目的制限と転送制約からも免除される。

オムニバス提案のpersonal dataの定義に関するリスクは、この第二のレベルで最もよく理解される。

3.2 相対的なpersonal data定義が流通ガバナンスをどのように損なうか

オムニバス提案は、personal dataの地位が特定の管理者の手段に依存しうるという考えを発明したのではない。それは裁判所の相対的アプローチ、特により最近の判例法で表明されたものを法典化している。核心的な考えは、情報がある管理者にとってpersonal dataとしてカウントされるのは、その管理者が当該個人を識別するために「合理的に使用される可能性がある」手段を持っている場合に限られるというものである。再識別のための鍵を持たない主体が保有する仮名化データセットは、たとえ別の主体が同じレコードを識別できるとしても、その主体にとっては定義の外に落ちる可能性がある。

表面上、この措置は現実の問題に対する技術的解決策として提示されている。すなわち、識別可能性を何らかの形で相対化しなければ、誰かが人物と結びつけうるあらゆるデータがすべての者にとってpersonal dataとして扱われるリスクがある、という問題である。しかし二層構造を見れば、異なる像が浮かび上がる。

単純化した仮想事例を考えよう。ある会社が、顧客がジャズ、ロック、クラシックのどれを好むかという音楽の好みに関する情報を、安定した内部識別子に紐づけて収集している。収集時点で、データを仮名化し、純粋に市場調査のためにのみ使用すると宣言する。相対的な定義の下では、会社は次のように主張しうる。

識別子から現実世界のアイデンティティへのマッピングを保持していない
個人を識別するために合理的に使用される可能性がある手段を現在持っていない
したがって、このデータセットは自社にとってpersonal dataではない

もしこの立場が認められれば、決定的な帰結が生じる。目的制限がデータセットに一切付着しない。データは構造化された形式で収集・処理されているが、その管理者にとって「非個人」として扱われる限り、データ保護の流通ガバナンス層全体が単純に適用されない。

数年後に早送りしよう。会社は戦略を変更し、信用スコアリング市場に参入する。そのデータセットにおいて、音楽の好みが返済履歴と相関することを発見する。今や会社には、以下の強いインセンティブがある。

識別子と個人との紐付けを再確立または取得する
既存の音楽の好みデータセットを与信決定への入力として再利用する

その時点で、会社は今は識別手段を持っており、データは今はpersonal dataを構成すると主張するだろう。しかし目的制限は遅すぎる形で援用される。データが当初「非個人」として分類されていたため、その収集と保持を特定の限定された目的のセットに結びつける法的義務も、後の信用スコアリングへの再利用を、新たな法的根拠と当該個人への新たな保証を必要とする目的変更として扱う義務もなかった。

これは奇抜なエッジケースではない。それは「識別手段がないとの主張を通じた目的漂流」という体系的パターンを記述している。

収集時：非個人の地位を主張し（識別手段がない）、それによって目的制限と関連する制約を回避する
中間期：「非個人」としてデータセットを複製、分析、取引する最大限の自由を享受する
収益性の高い決定用途が現れた後のある時点：データを個人として再分類し、重大な決定に使用する。その時点で予防層はすでに失敗している

同じロジックは、孤立した会社だけでなく、主体の連鎖全体にも適用される。上流の主体が、再識別の鍵を持っていないことを根拠に、豊かで個人レベルの構造化されたデータセットを「非個人」として扱えるなら、それらのデータセットは、識別された人物と結びつけ、決定システムに組み込む手段とインセンティブを持つ主体に到達するまで、自由に流通しうる。目的制限はまさにそのような文脈横断的流通を制約するはずだった。相対的な定義は、普及の最も重要な段階においてその射程から外れることを容易にする。

欧州委員会に対し、実施法を通じて仮名化データセットの特定のカテゴリーを「非個人」として指定する権限を与えるオムニバス提案は、このリスクを悪化させるだろう。そのような指定がなされれば、構造化されたデータのクラス全体が、後に決定パイプラインに再統合されるのに完全に適している間も、単なる技術的な排気ガスであるかのように移動しうる。消失するのは、何か周辺的な透明性義務だけではない。流通の各段階において「これらのデータをこの次の文脈に移動させることを正当化する目的は何か？」と問う事前の要件が消失するのである。

決定と流通志向の観点からすれば、オムニバスの再定義の危険は、主としてGDPRを抽象的な意味で「広くなくする」ことではない。それは、構造化され、決定に使用可能なデータセットを、予防的な流通ガバナンス層がその最も重要な仕事をするまさにその段階において、その層から除外することである。

同時に、GDPRはその適用対象範囲条項の形で、すでにゲートを持っていることを思い出す価値がある。2条は、規則を「個人データの処理」に限定している。「GDPRは何にでも適用される」という広く聞かれる不満は、そのようなゲートが存在しないからではなく、processingが次第に「ある人物に関するあらゆる情報のあらゆる取扱い」へと平坦化されてきた──政治的想像力においては、AI訓練のためのウェブクローリングやその他の大規模分析を含めて──からである。オムニバス提案はこの過広認識を額面通りに受け取り、personal dataの定義そのもののレベルでそれを治療しようとしている。最大スコープ・パラダイムは逆方向から反応し、personal dataとprocessingの可能な限り広い解釈を擁護している。両方の動きに共通しているのは、processingの構造的概念を手つかずのまま放置していることである──そしてそれとともに、GDPRの適用対象範囲は体系的でファイル的な処理パイプラインを捉えるためのものであり、個人への散在するあらゆる言及を捉えるためのものではなかったという、本来の考えも放置している。

3.3 決定と流通志向のスコープ・テスト

この背景に照らして、保護の両方の層を真剣に受け止めるなら、スコープの問いを構成する別の方法が示唆される。personal dataとprocessingの概念をどこまで概念的に拡張できるかを問う代わりに、どの状況においてEUのデータ保護法が、最低限、両方の層にわたって完全な力で適用されなければならないかを問うべきである。

決定と流通志向のテストは、予告的に、次のように定式化できよう。

体系的なパイプライン
processingの本来の意味での体系的な情報パイプラインが存在しなければならない。安定したカテゴリーやフォーマットに従って組織化されたデータに対する、構造化された一連の操作であり、単なる孤立した言及やアドホックなやり取りではない。これが、「データ」を散在する「情報」から区別し、初期のデータ保護法制が規制しようとしたものを捉える閾値である。
決定文脈
このパイプラインの産出物が、個人の法的・社会的地位に影響を与える決定文脈──信用、雇用、保険、社会給付、サービスへのアクセス、法執行、およびそれに類する領域──で使用される、または合理的に使用される可能性がある。ここで決定層が作動し、5条1項(c)は、処理される各データカテゴリーと表明された決定目的との間に合理的な関連を要求する、真正な関連性要件として解釈・執行されなければならない。
文脈横断的流通リスク
パイプライン内のデータが、目的制限と転送制限が適用されない限り、それらが関連性を持たない別の決定文脈に現実的に流入しうる。このような文脈横断的な漂流が構造的にあり得る場合──大規模分析、AI開発、プラットフォームエコシステムにおけるように──流通層は、管理者が現時点で識別手段を持っていると主張するかどうかにかかわらず、データが構造化された形式で収集された瞬間から適用されるべきである。

この見方によれば、オムニバスのpersonal data再定義の問題は、最大スコープという抽象的な理想を放棄することではない。問題は、それが管理者がこの三部構成のテストから任意に離脱することを許容する点にある。収集時点で識別手段を持たないと宣言するだけで──たとえ後に重大な決定システムに投入されうるような構造化されたデータセットをまさに構築している最中であっても──テストから外れることができてしまう。そのようなデータセットがpersonal dataという法的カテゴリーの外側で生まれてしまえば、その将来の流通を事前に形成する法の能力は損なわれる。

同じテストは、概念的に、AI関連処理の異なる類型を区別するのにも役立つ。散在する公開テキストコーパスに対する生成AIの訓練は、第一と第三の要件を満たさないかもしれない。それは体系的で個人宛（individual-addressable）のデータセットを作成せず、その産出物は自然に決定文脈に接続されない。対照的に、処遇AI──信用スコアリング、採用アルゴリズム、保険価格モデル──は三つの要件すべてに該当する。構造化されたレコードを操作し、個人に関する決定を直接支援し、そのデータセットには明らかな文脈横断的再利用可能性がある。

3.4 指令の歴史に照らした「個人データの処理」の再解釈

この解釈的提案は、GDPR 4条1項の条文を書き換えることを求めるものではない。既存のprocessing of personal dataおよびpersonal dataという概念を、その指令時代の機能に照らして読み直すことを求めるものである。

歴史的に、processingの構造的理解は、時代遅れの「ファイル」概念の偶然の副産物ではなかった。欧州委員会の1990年提案はなおファイルの言葉で語っていたが、欧州議会が「ファイル」を「個人データの処理」に置き換えることを主張したとき、それは構造的要件を完全に放棄することを意味していなかった。それは、文字通りの中央集権的ファイルなしに同じリスクを再現するオンザフライの決定システムを含め、ファイル的な処理パイプラインを捉えることを意図していた。「ファイル」から「個人データの処理」への移行は、概念を機能的な線に沿って拡張したのであり、「あらゆる情報のあらゆる取扱い」へと溶解させたのではなかった。

一部の判決──特に境界事例において──は、processingを「あらゆる情報のあらゆる取扱い」という一般則に変換することなく、特定の事実関係のために概念を拡張したものとして読むことができる。真の緊張が残る場合、それは、基礎にある概念がなお慎重な教義的明確化を必要としているまさにその時に、オムニバスが最大主義的スコープを憲法化するのは時期尚早であることを示唆している。

4. 結論：スコープをめぐる戦争ではなく、データ保護の本来の目的を取り戻す機会

デジタル・オムニバスをめぐる公開書簡やプレスリリースだけを読めば、おなじみのドラマに見える。一方には、個人データの定義を狭め、AIや研究のための新たな適用除外を設けることでGDPRを「骨抜きにしている」と非難される欧州委員会。他方には、個人データの最大スコープとデータ最小化の強いバージョンを擁護するnoybその他のアクター。

本稿で私が以前の分析を踏まえて主張してきたのは、これが間違った対立軸だということである。両陣営とも、法の射程をどこまで広げるべきかをめぐって争っているが、法が本来何をコントロールするために設計されたのかという点はほとんど無視している。1970年代以降、欧州のデータ保護法は抽象的な「データ」を対象としていたわけではない。それは意思決定システムを対象としていた。構造化されたデータが収集され、組織化され、雇用、信用、保険、社会給付その他の利益と負担を配分するために使用されるパイプラインである。

この観点から見れば、GDPRの核心は「データが多すぎる」ことへの抽象的な恐怖ではなく、一対の関連する問いである。個人に関する決定においてどのデータが正当に考慮されてよいのか、そしてデータが目的と合理的な関連を持たない決定文脈に流入することをどのように防ぐべきか？これこそが、データ品質原則と目的制限が本来対処するために構築されたものである。

ここで、二つの自然な疑問が浮かぶかもしれない。

第一に、これは結局、名前を変えたデータ最小化ではないのか、という疑問である。結局のところ、GDPR 5条1項(c)は今や文字通り、データは処理目的との関係で「十分であり、関連性があり、必要なものに限定される」べきだと述べており、データ保護指令もすでに「十分であり、関連性があり、過度でない」と述べていた。法は常にデータを最小化することを目指してきたのではないか？

私の答えは、歴史的に見れば、この三要素は決定のためのデータ品質原則として構成されていたのであり、「できるだけ少ないデータを収集せよ」という宙に浮いた命令ではなかった、というものである。「過度でない」──そして後に「必要なものに限定される」と言い換えられたもの──は、所与の決定目的にとっての十分性と関連性をも要求する基準の中に埋め込まれていた。監督当局のガイダンスはしばしば「十分」を「表明された目的を適切に果たすのに足りている」と解説している。しかし「足りている」は時として、より少ないデータではなく、より多くのデータを意味する。恣意的な信用拒否を避けるためのより完全な収入情報、単一のデータポイントの誤解を避けるためのより多くの文脈、粗雑なプロファイリングを防ぐためのより多くのニュアンス。「より少ないデータ」を基本権の観点から常により良いと扱う純粋な最小化の読み方は、この両義性を消し去り、十分性と関連性を一次元的な「量」の指標に押しつぶしてしまう。この観点からすれば、5条1項(c)をデータ最小化原則とリブランドすること自体が問題の一部なのである。それは決定にとっての関連性と十分性という本来の焦点を覆い隠し、より良い保護が実際にはより薄いデータではなくより良いデータを必要とする状況を見落としやすくする。

第二の、密接に関連する疑問は、これは結局、自動化された意思決定に関するGDPR 22条の強化を求めることに帰着するのではないか、というものである。22条をめぐる最近の戦いは、ある意味で、同じ誤った枠組みの症状である。データ品質原則がpersonal dataを考慮に入れるすべての決定の情報的基盤をすでに規律していることを忘れているがゆえに、プロファイリングやAIに関するあらゆる懸念を、22条の「専ら自動化された」決定という狭いカテゴリーに背負わせる傾向がある。そこで一方の陣営は、実際には5条1項(c)の一般的レジームに属する問題を治癒してくれることを期待して、22条をますます広げることを要求する。もう一方の陣営は、22条は十分性と関連性を尊重した適切なプロファイリングさえも烙印を押す行き過ぎだと結論づけ、それを骨抜きにするか廃止することを推進する──この雰囲気はオムニバス論争においても皆無ではない。

両陣営が忘れがちなのは、22条は非常に小さなサブセットのケースのための特別法（lex specialis）だということである。私がここで再構成しようとしてきた基本的な基準は、より一般的でより基本的なものである。それは、自動化と人間の関与の組み合わせがどうであれ、personal dataが意思決定に使用されるすべての場合に適用される。その基準が主として根拠を置くのは5条1項(c)および周辺のデータ品質・目的制限規定であり、22条ではない。22条を強化することは、関連性要件を全面的に真剣に受け止めることの代替にはなりえない。22条を弱体化しても、決定層における十分性と関連性を無視し続け、無関係なデータが重大な決定に密かに浸透できるように流通ガバナンスを緩和するなら、決定システムが無害になるわけではない。

この背景に照らせば、デジタル・オムニバスの真の約束と危険がより明確になる。約束とは、現在の論争が基本的な問いを再び開かせる契機となりえたはずだということである。構造的な意味で「個人データの処理」として何がカウントされるのか？データ保護の特徴的なリスクは実際にはどこで生じるのか？統計・学習フェーズと運用上の意思決定をどのように区別すべきか？危険とは、processingの基礎概念がなお慎重な教義的作業を必要としているまさにその時に、最大主義的なスコープ解釈を憲法化してしまうこと──そして同時に、最も緊急に厳格な流通ガバナンスを必要とするまさにその構造化されたデータセットのために、密かにバックドアを開けてしまうことである。

本稿で素描した代替案は、条文上の野心は控えめだが、効果においてはラディカルである。それは4条1項を書き換えることを求めていない。「個人データの処理」と5条1項(c)を、その指令時代の機能に即して読み直すことを求めている。AI訓練は既存のルールの下で統計処理として扱われるべきであり、真の規制上のエネルギーは、十分性と関連性の要件がついに効力を発揮しなければならないAI運用やその他の決定システムに向けられるべきだと提案している。そして、欧州委員会もその批判者たちも、personal dataという法的概念をどこまで引き伸ばせるかから、データが決定に流入するパイプラインを法がどのように規律するかへと注意を移した方がよいと提案している。結局のところ、それこそがデータ保護の存在理由だったのだから。

*1 例えば、ドイツが歴史的にデータ品質原則を一度も理解した様子がないことを裏付けるには、1973年のSpiros Simitisの初期の構想「Datenschutz - Notwendigkeit und Voraussetzungen einer gesetzlichen Regelung」（DVR 2巻138頁以下）で「Relevanz」概念がどう書かれていたか、1977年のOtto Mallmannが「Zielfunktionen des Datenschutzes: Schutz der Privatsphäre, korrekte Information; mit einer Studie zum Datenschutz im Bereich von Kreditinformationssystemen」で、信用情報システム分野を題材に、被影響者の差別のリスクに言及しながら「正確性」「完全性」に並び「文脈依存性の維持」を挙げて問題の本質に迫っていたにもかかわらず、その出口を必要性（Erforderlichkeit）に求めてしまったこと、その後もSimitisは一貫して何らかの具体的基準の必要性を訴え続けるものの、その答えは示されず、2000年ごろから出口が見えないままDatensparsamkeitに傾倒して行き、ついにはHans Peter Bullに、データ禁欲（Datenaskese）とか正気か？と窘められるという展開があったこと、Bull自身は、データ保護の趣旨を正しく理解し、より多くのデータ項目を要することもある旨を指摘していた（しかしDPDのデータ品質原則がそれをカバーしていることには触れていない）こと、ドイツでも労働法分野では古くから関連性（sachlicher Zusammenhang）を要件とする判例と学説が確立していたが、データ保護法制のデータ品質原則がそれをカバーしているとは気づいていない様子がある（Peter GolaのBDSGコンメンタールなど）こと、国内法のBDSGは長らくDPDのデータ品質原則を無視して（比例原則と勘違いして）導入しなかった（対応済みだと勘違いして）こと、それが原因でSCHUFAの住所を用いたGeoscoringに対処できず、BDSG 2010で個別の規制条項を導入していること、それにもかかわらず問題は解決せず、結局GDPR 22条に活路を見出そうとして現在も迷走していること、Alexander Roßnagelが、1990年代から2010年代にかけて常にDatensparsamkeitを強調し、GDPRの成立に際しても、Datensparsamkeitが徹底されなかったことを指摘し、22条の自動決定規制をもっと強化すべきとGDPRの改正を主張していたこと、などなどを示す必要があるだろう。情報的自己決定権を持ち出してDatensparsamkeitを強調する者には、国勢調査判決以来の「Informationelle Selbstbestimmung」がドイツの学説でどう論じられてきたか、特に2010年のGabriele Britz「Informationelle Selbstbestimmung zwischen rechtswissenschaftlicher Grundsatzkritik und Beharren des Bundesverfassungsgerichts」（Offene Rechtswissenschaft: ausgewählte Schriften von Wolfgang Hoffmann-Riem mit begleitenden Analysen、561頁以下）がどう結論づけているかなどを挙げるのがいいし、ドイツ以外でのデータ保護法制のrelevant要件の意味が、本当に私の言うような意味のものだったのかについては、Paul SieghartやJon Bingの文献の他、英国Lindopレポートの記述と、米国FCRA 1970立法過程の公聴会の記録を参照するのがよいだろう。

*2 このことは日本にとっても他人事ではない。生成AIの台頭に伴って日本の個人情報保護委員会も一昨年、要配慮個人情報の収集についてOpenAI社に対して無理のある注意喚起を出し、保護の方向性について自民党から疑問視される事態になっていたのは、欧州とよく似た状況である。ちょうどその頃始まっていた日本の個人情報保護法の3年ごと見直しでは、この問題に対処するべく、私の提出意見が通り、生成AIの学習段階を統計処理と捉えて、要配慮個人情報が含まれてしまうことを問題視しないようにする改正が予定（昨日の新聞報道）されている。

本日のリンク元 TrackBack(0)

2025年12月16日

■ 知財検討会にまで及ぶAI規制の混迷──処遇AIと生成AIを混ぜると、全部壊れる

Twitterで、12月12日の「AI時代の知的財産権検討会（第10回）」の配布資料「AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル型コード（仮称）（案）」が、これはひどいと話題になっているのが流れてきたので、読んでみたところ、色々言いたいことが思い浮かんだ。本来ならば論文で指摘するべき話だが、他に先に書かないといけないことばかりで、いつになったらできるかわからない。今動いている話なので、急ぎここに記す必要があるが、書くのが面倒なので、生成AIに書かせた。自分で書けばぐちぐちと悩みながら2、3日かけるところだが、もはや生成AIのおかげで、気づいてから半日で完成だ。（どういうプロンプトで書かせたかは末尾に開示しておく。）

関係者の皆さんには読んでほしい。方向付けさえすれば自然にここまで言われてしまうという事態の深刻さを受け止めてほしい。

知財検討会にまで及ぶAI規制の混迷──処遇AIと生成AIを混ぜると、全部壊れる

5月に「処遇AIと生成AIの区別ができていない」と指摘した。国会審議で、処遇AI（人事評価の差別）について質問されているのに、大臣が生成AI（差別を助長する出力を防ぐ）のことを答弁してしまう事態が起きていた。AI事業者ガイドラインの「差別」「バイアス」への言及も、精査してみると生成AIの出力についてしか述べられていなかった。

12月には欧州向けに、EUのDigital Omnibus規則案についても同様の混同が起きていると批判した。欧州委員会もnoybも、「GDPRのスコープを広げるか狭めるか」という間違った軸で戦っており、データ保護法の本丸である「決定の適切性」と「関連性の原則」が見失われている、と。

そして今、さらなる混同が発生している。今度は「知財面からのAI規制」においてである。

先週金曜日（12月12日）に開催された「AI時代の知的財産権検討会」第10回会合の資料が公開され、「プリンシプル・コード（仮称）（案）」が示された。これを見た人々からX上で悲鳴が上がっている。

「日本が20年続けてた負けパターンに嵌ってきた感」「クソデカため息しか出ない」「会議内容から失われた日本を絶対に取り戻さない強い意志を感じる」——。

政府は「世界で最もAIを開発・活用しやすい国」を標榜している。その方針自体は正しい。だが、この資料を見る限り、その方針とは真逆の方向に進んでいるように見える。

より具体的な指摘もある。「責任追跡を書類と掲示で担保しようとしている」「全部書けば透明性と思っていそう」「新聞で言えば取材源を全部公開しろと言っているようなもので、副作用を考えていない」「学習データ開示やログ管理が数兆トークン規模で不可能」「EUに合わせた以外の根拠がない」「OpenAIは絶対応じないだろう」——。

さらに、「EU AI Actをほぼ丸パクリしつつ強制力なしのため正直者だけバカを見る」「ゲーム開発者も対象になり得る定義の広さで、国外事業者は無視して国内だけ萎縮する」「NDAや営業秘密のセーフハーバー（免責）が考慮されていない」といった指摘もある。

これらの不満は、感情的な反発ではない。制度設計として当然の帰結を指摘している。問題は「規制が厳しいか緩いか」ではない。規制の目的と手段が噛み合っていないのである。

何が問題視されているのか

知財検討会の第10回資料2「プリンシプル・コード（仮称）（案）」を見ると、「透明性確保のための措置」として、学習データ、クローラ、トレーニングプロセス等の開示が列挙されている。ここまでは知財（著作権）の観点から一定の合理性がある。

なお、この文書は自ら「EU AI Actにおける取組」を参照し、「comply-or-explain」方式を採用すると明記している。EUを手本にしていることは、文書自身が認めているところである。

問題はその先である。同じ「透明性」の箱に、「アカウンタビリティ関係」として次の記述がある。

AIシステム・サービスの開発・提供・利用中に行われた意思決定等について、技術的に可能かつ合理的な範囲で追跡・遡求が可能な状態の内容（記録方法、頻度、保存期間等）

そしてこの根拠として、脚注でAI事業者ガイドラインの「検証可能性の確保」を引用している。そこにはこう書かれている。

AIの判断にかかわる検証可能性を確保するため、データ量又はデータ内容に照らし合理的な範囲で、AIシステム・サービスの開発過程、利用時の入出力等、AIの学習プロセス、推論過程、判断根拠等のログを記録・保存する

ログの記録・保存にあたっては、利用する技術の特性及び用途に照らして、事故の原因究明、再発防止策の検討、損害賠償責任要件の立証上の重要性等を踏まえて、記録方法、頻度、保存期間等について検討する

「AIの判断」「推論過程、判断根拠」——これは何のための規律か。「事故の原因究明」——これはまた別の話ではないか。

処遇AI、生成AI、そして製品AI

ここで改めて、5月から使っている概念を確認し、一つ追加しておく。

処遇AIとは、個人をデータに基づいて他の個人らと異なって扱うことを目的としたAIである。採用判定、与信判断、保険料算定、行政給付の決定、監視対象の選別などがこれに当たる。処遇AIの規律で問題となるのは、決定の適切性である。関連性のないデータで人を分けていないか。誤ったデータで不利益な決定をしていないか。不当な差別が生じていないか。決定に対して異議申立ての途が開かれているか。

生成AIとは、表現（文章、画像、音声など）を生成するAIである。生成AIの規律で問題となるのは、主に出力段階の問題である。ディープフェイク、偽情報、出力が既存著作物に類似する場合の著作権侵害、悪用防止などがこれに当たる。学習段階で問題となるのは、取得手段の違法性（不正アクセス等）程度である。

製品AIとは、物理的な動作や制御を担うAIである。自動運転車、産業用ロボット、医療機器などがこれに当たる。製品AIの規律で問題となるのは、製品安全である。事故が起きたときの原因究明と再発防止がこれに当たる。従来の製品安全法制の延長線上にある。

この三つは、規律の目的が根本的に異なる。

処遇AIで必要な「透明性」は、本人救済と監査のための透明性であり、「この人をこう扱った理由」が争える形で残っていることを意味する。

生成AIで必要な「透明性」は、出力段階での検証と悪用抑止のための透明性であり、「生成物がAI製であること」の表示や、問題ある出力への対応窓口などを意味する。

製品AIで必要な「透明性」は、事故調査のための透明性であり、「何が起きたか」を事後に再現できることを意味する。

三者を混ぜると、規制は必ず変になる。

何が混同されているのか

プリンシプル・コード案の「意思決定等について…追跡・遡求が可能」という文言は、実は二通りに読める。

一つは、「事業者の意思決定」——開発・提供・利用を決めた経緯の記録という読み方である。これなら知財紛争での立証に関係しうる。

もう一つは、「AIの意思決定」——AIが個人に対して行った判断の記録という読み方である。これは処遇AIの規律に属する。

文言だけなら前者の読み方も不可能ではない。だが、脚注で引用されているAI事業者ガイドラインを見れば、話は明らかである。ガイドラインは「AIの判断」「推論過程、判断根拠等のログ」と言っている。これは「事業者がどう決めたか」ではなく、「AIがどう判断したか」の記録を求める語彙である。

さらにガイドラインは、ログの目的として「事故の原因究明」を挙げている。これは製品AI寄りの語彙である。

知財検討会は知財（著作権）の問題を扱う場である。著作権の観点から透明性が問題になるとすれば、取得手段の適法性や、出力が既存著作物に類似する場合の検証などであって、「AIがどのような推論をしたか」や「事故原因の究明」ではない。

ところが知財検討会の「プリンシプル・コード案」は、AI事業者ガイドラインの「検証可能性」をそのまま引用している。処遇AI向けの「AIの判断ログ」と、製品AI向けの「事故・安全」の語彙が、生成AI×知財の文脈に「キーワード」として流れ込んでいる。「透明性」という一語の下に、目的の異なる規律が同居してしまっている。

これがまさに、X上で指摘されている「全部書けば透明性と思っていそう」の正体である。

EU AI Actでは区別されている

この文書が自らEU AI Actを参照しているというなら、EU AI Actの構造を確認しよう。

EU AI Actでは、ログ・トレーサビリティの義務は高リスクAI（その多くが処遇AIに当たる）に課されている。Article 12は、高リスクAIシステムがイベント（logs）の自動記録を技術的に可能にすべきことを定め、その目的を「高リスクAIシステムの機能の追跡可能性（traceability of the functioning）」と明示している。採用判定や与信判断などに用いられるAIでは、誰がいつどのように評価されたかを事後に検証できるようにするためである。Article 86には「個人の決定に対する説明を受ける権利（Right to explanation of individual decision-making）」まである。

一方、GPAI（汎用目的AI）モデルに課される義務は別の束である。Article 53は、技術文書の作成、下流事業者への情報提供、著作権ポリシーの策定、学習データの要約の公開などを求めている。ここには「個別の意思決定ログ義務」は含まれていない。

つまりEUは、高リスクAI（処遇AI寄り）とGPAI（生成AI寄り）で義務の束を分けている。ログ・トレーサビリティは高リスクAI向けであり、GPAIには「技術文書」「著作権ポリシー」「学習データ要約」という別の透明性が課されている。

日本が「EU整合」を唱えるなら、輸入すべきはキーワードではない。輸入すべきは「区別」である。

なぜこうなるのか

EUから聞き齧ったルールが「何のためにどのように働くルールなのか」を理解しないまま、キーワードだけを輸入する。「透明性」「追跡可能性」「責任」「Code of Practice」「robots.txt」「EU整合」——こうした単語を、目的も前提も異なる領域にベタ貼りする。

すると何が起きるか。「どの害を防ぐためのルールか」という問いが消え、「とにかく開示」「とにかくログ」「とにかく掲示」という書類主義の万能薬になる。

X上の不満はその帰結である。「全部書けば透明性」「取材源公開みたい」「根拠がない」——これらは感情的反発ではなく、制度設計の欠陥への正当な指摘である。

だが、なぜキーワードが「流れ込んでくる」のか。それは、本来の居場所で定着していないからである。

処遇AIの規律が宙に浮いている

「追跡可能性」「検証可能性」「ログ」——これらは本来、処遇AIの領域で使われるべき語彙である。人を選別するAIにおいて、「なぜこの人をこう扱ったのか」を事後に検証し、争えるようにする。そのための規律である。

そして処遇AIの規律の本来の居場所は、個人情報保護法である。個人データに基づいて人を評価し、決定する——これこそが個人情報保護法制の本丸の保護利益である。私は個人情報保護委員会の3年ごと見直しに提出した意見書でもこの点を指摘している。

ところが、処遇AIの規律が正面から設計されていない。だから語彙だけが浮遊し、関係のない領域に紛れ込んでくる。

5月の国会審議では、処遇AI（人事評価の差別）についての質問に対して、大臣は生成AI（差別を助長する出力を防ぐ）のことを答弁した。AI事業者ガイドラインの「差別」「バイアス」への言及も、精査すると生成AIの出力についてしか述べられていない。

処遇AIで本当に必要なのは、決定ガバナンスである。目的の明確化（何の決定のためのAIか）、入力データの関連性（決定目的に関係ないデータで人を分けない）、正確性・最新性、不当な差別の検証、異議申立て・再審査・人手関与、そして監査可能性（ログ）——ただし「全部開示」ではなく、救済と監督のための合理的範囲で。

この本丸が宙に浮いているから、「追跡可能性」「ログ」という言葉だけが一人歩きし、知財検討会のような場にまで流れ着く。もちろん、知財検討会で処遇AIの規律をやれという話ではない。だが、しかるべき場所で本丸が設計されていれば、知財検討会は知財の問題に集中できたはずである。

区別すれば、双方の不満が解ける

いま起きている混乱は、規制の「強さ」の問題ではない。規制の「カテゴリ誤り」の問題である。

処遇AI、生成AI、製品AIを区別すれば、それぞれの不満が同時に解ける。

生成AI側では、出力段階の問題（ディープフェイク、偽情報、悪用）への対応を中心に透明性を組み立てる。「全部開示」ではなく、問題ある出力への対応窓口や、生成物がAI製であることの表示などである。

処遇AI側では、決定ガバナンス（関連性・救済）を本丸として、しかるべき場所で制度化する。ここで初めて「透明性」「追跡可能性」「ログ」という語彙が本来の意味を回復する。人を選別する領域でこそ、これらの規律は意味を持つ。

製品AI側では、従来の製品安全法制の枠組みで、事故調査・原因究明の仕組みを整備する。

5月、12月と続けて指摘してきた問題が、今度は知財の領域にまで及んでいる。このまま放置すれば、AI規制は誰も得をしない形で迷走を続ける。

第10回会合の議事録はまだ公開されていない。委員の先生方からこの点について的確な指摘があったのかどうか、気になるところである。

続いて、AIネットワーク社会推進会議の「AIガバナンス検討会（第28回）」の資料「AI事業者ガイドラインの更新に向けた論点」の話も流れてきたので、これも同じ話なので上記の続編としてAIに書かせた。これも合わせて一度に掲載してしまおう。

AI事業者ガイドラインにも同じ病巣──技術軸でキーワードを増やしても、規律の目的は整理できない

前回、知財検討会の「プリンシプル・コード案」が、処遇AI向けの規律（追跡可能性、ログ）を生成AI×知財の文脈に持ち込んでいる問題を指摘した。「透明性」という一語の下に、目的の異なる規律が同居してしまっている、と。

だが、これは知財検討会だけの問題ではない。知財検討会が脚注で参照したAI事業者ガイドライン自体に、同じ病巣がある。

AI事業者ガイドラインの更新議論

12月2日に開催されたAIガバナンス検討会（総務省・経産省）で、AI事業者ガイドラインの次期更新に向けた論点が示された。

主な論点は三つ。第一に、AIエージェント／エージェンティックAIに関する記載の追加。第二に、フィジカルAIに関する記載の追加。第三に、リスク評価手法の追加である。

一見すると、技術の進展に対応した妥当な更新に見える。だが、ここにも同じ問題が潜んでいる。

「AIエージェント」という箱に何が入っているか

資料に示されたAIエージェントのリスク案を見ると、異質なものが同一リストに並んでいる。

判断根拠が不明瞭──非決定的な判断で根拠の追跡が困難

誤情報の拡散──間違いを繰り返し学習・出力して広める

ツールの悪用──許可された範囲のツールで意図しない操作を実行

権限の乗っ取り──他のシステムから権限を奪い高い権限を取得

人間の過信誘導──AIを過信させて有害な行動に導く

「判断根拠の追跡」は、処遇AIで「なぜこの人をこう扱ったか」を検証するための規律なのか、それとも製品AIで「事故原因を究明する」ための規律なのか。「誤情報の拡散」は生成AIの出力段階の問題である。「権限の乗っ取り」はセキュリティの問題である。「人間の過信誘導」はまた別の問題系である。

「AIエージェント」という技術的特性で箱を作ったため、規律の目的が異なるリスクが一緒くたになっている。これでは、それぞれのリスクに対して「何をすべきか」が見えてこない。

フィジカルAIは製品AIに対応する

一方、フィジカルAIのリスク案を見ると、比較的整合が取れている。

物理的事故の発生──ロボットの誤作動で人や物に損害を与える

判断のブラックボックス化──内部処理が不透明で原因特定や責任追及が困難になる

これは前回整理した「製品AI」に対応する。自動運転車や産業用ロボットなど、物理的な動作を担うAIでは、製品安全が問題になる。「事故原因の究明」「責任追及」という語彙は、この文脈でこそ意味を持つ。

フィジカルAIについては、規律の目的（製品安全）と手段（事故調査のためのトレーサビリティ）が対応している。「判断のブラックボックス化」が問題になるのは、事故が起きたときに原因を特定できないからである。

では処遇AIはどこに？

リスク評価の手法を議論する箇所で、EU AI Actの高リスク8領域が「参考」として挙げられている。

バイオメトリクス（顔認証など）
雇用・労働管理（採用選考、昇進判定、業務配分など）
教育・職業訓練（入学・受講の可否判定など）
公共・民間サービス（医療、金融、保険のアクセス判定など）
法執行（犯罪予測、捜査支援など）
移民・国境管理
司法

これらはまさに処遇AI的な領域——個人をデータに基づいて評価・選別・決定する用途——である。

だが、これは「リスク評価の参考」として言及されるだけである。処遇AIの規律の本丸——関連性のあるデータのみを使う、不当な差別を検証する、異議申立ての途を開く、救済可能な形でログを残す——は正面から扱われていない。

技術軸（AIエージェント、フィジカルAI）の議論が中心になり、「何のための規律か」という目的軸の整理が抜け落ちている。

事業者からの悲鳴

同じ資料には、AI事業者ガイドラインの利活用に関する事業者からの意見が並んでいる。

全体像を簡単に理解するのが困難な文章量になっているのが現バージョンの最大の問題点だと思います。

項目間の対応・依存関係が不明なため検索しづらい

本文の方は、概念を整理し、何を行うべきか（What）を網羅的に掲載しようとしているように見える。別の言い方をすると、辞典やリファレンスマニュアルのような構成になっている。一方、このガイドラインの想定される利用者は、自分達でやりたいことがあり、その際に具体的に実施すべき手順（How）を知りたいのであろう。

文章中には一部、“適切な”等の漠然とした表現の箇所があるため、具体的にどうすればいいのかわからないと思う方もいるのではないかと推測します。

これは「キーワード政策」の当然の帰結である。

規律の目的を整理しないまま、「透明性」「追跡可能性」「責任」「公平性」といったキーワードを技術軸の箱に放り込むと、すべてが抽象的になる。「何のために」「誰に対して」「どのような場面で」が明確でないまま「適切に対応せよ」と言われても、事業者は動きようがない。「辞典みたいでHowがわからない」という苦情は、まさにこの構造から生じている。

技術軸でキーワードを増やしても、規律の目的は整理できない

問題の構造はこうである。

現行のガイドラインは技術軸で分類している。従来AI、生成AI、AIエージェント、フィジカルAI……と、技術の進展に応じてカテゴリが増えていく。

だが、規律の目的は技術軸と一致しない。本来あるべき整理は目的軸である。

処遇AIでは、決定の適切性が問題になる。関連性のないデータで人を分けていないか。不当な差別が生じていないか。決定に対して異議申立ての途が開かれているか。

生成AIでは、出力段階の問題が中心になる。ディープフェイク対策、偽情報対策、著作権との関係。

製品AIでは、製品安全が問題になる。事故が起きたときの原因究明と再発防止。

技術軸でキーワードを増やしても、規律の目的は整理できない。むしろ、新しい技術カテゴリ（「AIエージェント」など）が登場するたびに、異なる目的の規律が同一の箱に混入し、混乱が増殖する。

問題の根源

知財検討会の問題は、AI事業者ガイドライン自体の問題でもある。

ガイドラインが「キーワード辞典」になっているから、下流の検討会で参照されるときに、目的の異なる語彙が文脈を無視して流入する。事業者が「何をすればいいかわからない」と困惑するのも当然である。

解決策は、技術軸ではなく目的軸で規律を整理し直すことである。処遇AI、生成AI、製品AIの区別を明確にし、それぞれに固有の規律を設計する。そうすれば、「何のために何をすべきか」が見えるようになり、キーワードの一人歩きも止まる。

政府は「世界で最もAIを開発・活用しやすい国」を標榜している。だが、規律の目的を整理しないままキーワードを増やし続ければ、「何をすればいいかわからない」ガイドラインが肥大化するだけである。それは開発・活用のしやすさとは正反対の帰結をもたらす。

さて、どのようなプロンプトでこれらを書かせたかであるが、もういちいち掲載するのも面倒だが、開示しておこう。

まず、ChatGPT 5.2 Thinkingに、Twitterで噴出している不満を把握させ、私の基本的立場を示し、政府資料を把握させ、批判の方向性を指示し、引用すべき箇所を把握させ、それらの材料を使ってブログの骨組みを提案させ、論調のトーンを指定して、本文を書かせてみた。しかし、ChatGPTの日本語作文は下手なので、これらの会話をClaude Opus 4.5に与えて、状況を把握させ、ChatGPTと並行して重要な箇所をいくつか指摘して方向性を定め、表題と本文を生成させた。そこから細かいところの修正を指示し、取り上げるTwitterでの反応を増やすために、Grok に調べさせて、その結果をClaudeの原稿に反映させた。

私：AI規制についてこのような不満が出ています。私はこれに解決策を提示しようと考えていますが、まず、出ている不満をこのリンクから把握できますか。
https://x.com/alfredplpl/status/2000437688730845531

ChatGPT：はい、少なくとも「そのポスト（と、それを引用して広がっている反応）」に出ている不満の筋は把握できます。

（略）

補足：X本体のページは、こちらの環境だと本文・スレッド全体を展開取得できず（検索結果に出てくる“本文断片”中心になります）、上は検索で確認できたテキスト断片ベースの整理です。もしスレッド中で「具体的にどの文書／どの条文（ガイドライン等）」を指しているかが分かる追加ポストがあれば、そこまで含めて不満の類型をもう少し精密に分解できます。

私：印刷してPDFにしました。

ChatGPT：PDF（1.pdf / 2.pdf）を見る限り、出ている不満はだいたい次の束に整理できます。

（略）

私：私から出そうと思う助け舟は、処遇AIと生成AIの区別です。この区別ができていないため、求めようとする規制がおかしくなっているのです。

ChatGPT：いい助け舟です。いまPDFに出ていた不満（「全部出せ」「書類主義」「国産が死ぬ」「OpenAIは従わない」「取材源公開みたいでプライバシー無視」）は、だいたい “処遇AIの規律”を“生成AI”にそのまま被せていることで発生している、と整理できます。

（略）

私：政府の検討会議がその点をどのくらいわかっていないかを示したいです。検索して議事録や資料を確認できますか。

ChatGPT：できます。すでに一次ソース（内閣府・官邸）側で、「生成AI」中心の問題設定になっていることが、議事要旨・とりまとめ案・関連コード案からかなり明確に読み取れます。あなたの「処遇AI vs 生成AI」切り分け論を打つための“材料”は揃います。

（略）

私：処遇AI向けの規律（生成AIブーム前に検討されていた）を生成AIに適用しようとしているのが悪い（このような不満につながっている）ということ、また逆に、処遇AI向けの規律を正面から定めようとしていないという問題、この両面から批判したいです。

ChatGPT：いい切り口で、批判が二段構えになるのが強いです。

（A）カテゴリ誤り：処遇AI向けの規律（決定・評価・選別を正すための規律）を、生成AIに“そのまま”当てはめようとしている
（B）空洞化：その一方で、本来いちばん必要な「処遇AIを正面から規律する」制度（権利・義務・執行）を立てていない

この2点を、同じ素材（政府資料・議事録＋今回の不満）で両側から刺せます。

（略）

私：そのような引用束の作成までお願いできませんか。引用の長さに制限があるなら、場所だけ示してくれるのでもいいです。

ChatGPT：以下、まず「出ている不満」（あなたが印刷したPDF＝Xスレ）を要約し、その後に政府側（検討会の議事要旨・資料）から“処遇AIと生成AIの区別が崩れている”ことを示せそうな引用束（場所つき）を並べます。

（略）

必要なら、次のステップとして「AI時代の知的財産権検討会」の“該当回”をもう2〜3回分追加して、（a）どこから“開示・透明性”が肥大化したか／（b）誰がEU整合を強く意識しているかを、議事要旨ベースで時系列の“引用束”に拡張できます。

私：ではそれ（もう2〜3回分追加して……）をやってください。

ChatGPT：了解です。前回こちらで拾った「第10回（透明性／追跡可能性・開示・ガイドライン運用）」に加えて、さらに3回分（第7回・第8回・第9回）について、“処遇AIの問題系がほぼ射程外のまま、生成AI（学習・生成物・robots.txt等）の規律発想だけが前に出ている”ことが読み取れる箇所を、引用ポイント（場所）として束ねます。

（略）

私：EUから聞き齧ったルールが何のためにどのように働くルールなのか理解しないまま、キーワード、ワンセンテンス政策？で間違った当てはめをして誰も顧みていないのではないか、という論調で行けませんかね。そのためには、EUも同様に混乱している可能性もあるところ、日本ほどひどくはないといった考察が有効かもしれません。

ChatGPT：（略）

私：ここまでの材料を使って、ブログの骨組みを構築しましょう。導入は不満が出ているところから始めると効果的です。

ChatGPT：了解です。いま集まっている材料だけで、「不満 → 何がズレているか → どこで混線しているか（一次資料）→ 本丸（処遇AI）が空洞 → 解決策（区別）→ EU比較 → 結語」の流れで、ブログの骨組みを組みます。

（略）

私：タイトルは今のところどれもイマイチですが最後に決めればいいでしょう。論調のトーンは強めでいきます。まずは本文を書いてみてください。

ChatGPT：（以下、強めトーンで「本文ドラフト」です。引用は短くし、長い箇所は“場所”で示します。タイトルは仮置きです。）

（略）

私：うーん、あまり上手なブログ文章ではないです。ChatGPTは日本語での文章生成に限界がありますかねえ。先日の英語ブログはお上手だったのに。いっそ英語で書いてみますか？

ChatGPT：（略）

私：ひとまずOK。しかしここで材料にしている第10回の資料ですが、これって、「AI時代の知的財産権検討会」の資料なので、我々の論点からはずれているのではないかな？
https://www.kantei.go.jp/jp/singi/titeki2/ai_kentoukai/kaisai/index.html

ChatGPT：はい、その懸念はもっともです。第10回資料（＝「AI時代の知的財産権検討会」系）は “AI規制一般” の会議ではなく、基本的に「生成AI×知財（著作権等）＋透明性」の文脈の会議です。実際、この検討会の中間とりまとめ自体が「AIと知的財産権に関する考え方の整理」を目的としている、と明記しています。

（略）

私：もしかして、知財検討会のくせに、EUのAI法から処遇AI規制のための透明性を導入しちゃってる構図？
問題の資料を念のためアップロードしますね。リンク元はここでした。
https://www.kantei.go.jp/jp/singi/titeki2/ai_kentoukai/gijisidai/dai10/index.html

ChatGPT：はい、この第10回資料（アップロードいただいた「プリンシプル・コード（仮称）（案）」）は、「AI時代の知的財産権検討会」なのに、EU AI Act 由来の“処遇AI（高リスクAI）っぽい透明性・説明責任パッケージ”を、そのまま生成AI（とくに学習・著作権）側に混載している構図がはっきり出ています。

（略）

私：添付するのはChatGPTとの会話です。残念ながらChatGPTは、日本語ブログを上手に書くことができないようです。Claudeさんならうまく書けるでしょう。課題認識はChatGPTが正しく把握しています。この課題認識をまず吸収して、Claudeで日本語ブログを生成すべく準備してください。

Claude：ChatGPTとの会話を拝見しました。課題認識は明確に把握できました。

私が理解した論点の構造

問題の核心：カテゴリ誤り

日本のAI規制議論が混乱しているのは、「処遇AI」と「生成AI」という、規律目的が根本的に異なる二つの領域を区別せずに、EUから聞き齧ったキーワード（「透明性」「追跡可能性」「責任」等）をベタ貼りしているからだ。

二面からの批判

誤適用批判：処遇AI向けに設計された規律（決定の監査可能性、説明責任）を、生成AI（学習・クローリング）にそのまま当てはめようとしている → 「全部開示」「取材源公開」的な過剰要求になり、現場の不満を招く
空洞化批判：その一方で、処遇AI（採用・与信・保険・行政処分など、人の扱いを変える決定）を正面から規律する制度が立っていない → 本当に危険な領域が手つかず

論調のトーン：「EU整合」という呪文で思考停止し、ルールの目的も働き方も理解しないまま「ワンセンテンス政策」で走っている政府への批判。強め。

この理解で正しければ、本文の執筆に入ります。ChatGPTの骨組みは概ね妥当ですが、日本語の文章としてはまだ硬く、論旨の流れにも改善の余地があります。私の方で書き直します。

私：大枠はそのとおりです。もう少し細部まで構成を確認してから、執筆をお願いしようと思います。

Claude：（略）

私：1は、(A)です。加えて(A)が問題視している(B)を引用すると良いでしょう。2は、この用語は5月から使っている言葉（https://takagi-hiromitsu.jp/diary/20250518.html 参照）ですが、改めて定義を説明するのが良さそうです。EUの高リスクAIと必ずしも一致しません。高リスクAIは処遇AIに該当するものばかり（かどうかは要確認）ですが、それに限られず、個人をデータに基づいて他の個人らと異なって扱うことを目的としたものはすべて処遇AIです。正確には、AIには、処遇AIと生成AIのどちらにも当てはまらないものがあります。自動運転車のAIなどで、そこでは製品安全の規制がAI法の目的となります。これらを区別する必要があるところ、特に問題となっているのは処遇AIの規律をはっきりさせない日本、生成AIへの過剰規制となっているEUと日本なので、この2つです。3については、「本文中に短く引用して論証に使う」です。4については、説得力を増す方向でお願いします。

Claude：（略）

私：1.独立です。参照は可。ところで、今気づいたのですが、ChatGPTの調査で材料にしていた、不満の声が参照している政府委員会が提示した「プリンシプル・コード（仮称）（案）」ですが、ソースを確認したところ、「AI時代の知的財産権検討会」の第10回（先週金曜日開催）からのようで、そうすると、知財の観点での議論なのに、我々がデータ保護法の観点から批判するのは的外れになるかもしれません。その点、ChatGPTにも伝えたところ以下の反応です。
https://www.kantei.go.jp/jp/singi/titeki2/ai_kentoukai/gijisidai/dai10/index.html

Claude：（略）

私：Claudeにも聞いてみたので、参考にしてください。

ChatGPT：はい、確認できます。結論から言うと、知財検討会の「プリンシプル・コード案」に、EU AI Actの“処遇AI（高リスクAI）向け”のログ／トレーサビリティ発想が「透明性／アカウンタビリティ」として混入している、という読みはかなり筋が良いです。

（略）

必要なら次は、この材料を使ってブログ本文の中核となる “カテゴリ誤り（treatment AI rules ≠ generative AI rules）” の段落を、英語・論文調で「引用（最小限）＋論証（厚め）」の形に組み直します。どの読者層（国内政策ウォッチャー向け／海外向け／研究者向け）に寄せますか。

私：これは欧州向けではなく完全に日本国内向けのブログになりますねえ。以下はClaudeに指示した結果です。

ChatGPT：了解です。国内向けなら、欧州比較は「言い訳」ではなく “日本がEU整合と言いながら、EUが（少なくとも条文構造としては）分けている箱を混ぜている”という指摘の補助線に留めるのが効きます。で、導入はご提案どおり「市民（現場）から絶望の声が上がっている」から入るのが一番刺さります。

（略）

私：「AIシステム・サービスの開発・提供・利用中に行われた意思決定等について」のところですが、これは、開発・提供・利用事業者がそのような開発・提供・利用をすることを決めた経緯の記録といっているように読めませんか？そして、これを真似る元にしたであろうEUではそこはどう書かれていたのかが問題ですね。

Claude：鋭いご指摘です。確かに「AIシステム・サービスの開発・提供・利用中に行われた意思決定等」は、二通りに読めます：

処遇AI的な読み方：AIが個人に対して行った意思決定（採用判定、与信判断など）の追跡
事業者の経営判断の読み方：事業者が「どのデータを使うか」「どのモデルを採用するか」を決めた経緯の記録

後者であれば、知財紛争での立証用（「我々はこういう判断でこのデータを使った」）として一応筋は通ります。

EUの元の条文を確認しましょう。

（略）

私：この指摘が正しいなら、政府の検討はかなり狂っていますね。議事録がまだ出ていないので、委員からどういう指摘があったかは不明ですが、おかしいとする指摘があって然るべき。その論旨で行くならかなりインパクトのある記事になりますが、それだけに事実関係を慎重に見極める必要があります。添付はこちらの議論をChatGPT側にも伝えて検証してもらった結果です。

Claude：（略）

私：構成を調整してください。断定的な批判を避けるべきかについては、単に言葉を弱めることは意味がないと思っており、根拠に基づき言えることは断言してよいです。問題提起の方向性として、5月にも書いていたように処遇AIと生成AIの区別ができていないから個人データ関係で規律の方向性がおかしくなっているという指摘（これは欧州向けにOmnibus規則案への批判としても今月書いた https://takagi-hiromitsu.jp/diary/20251206.html ）を超えて、今回さらに、知財面からのAI規制についてさらなる混同が発生しており、市民から絶望の声が上がっているみたいな流れで始めるのがよいと思う。

Claude：12月6日のブログ（Omnibus規則案への批判）を確認させてください。

（略）

12月6日のブログを確認しました。これで全体の流れが明確になりました。

構成案（改訂版）

タイトル案

「知財検討会にまで及ぶAI規制の混迷──処遇AIと生成AIを混ぜると、全部壊れる」

（略）

この構成でよろしいでしょうか？よければ本文の執筆に入ります。

私：OK、最後のパートでは、議事録が未公開なのでわからないが委員から的確な指摘があったか気になる旨を書いておきましょう。真意は「俺の話を聞けよ」ですが、まあそうは書かないで。委員の先生方も知ってる人多いしね。

Claude：承知しました。では本文を執筆します。

（略）

以上が本文案です。タイトルは後で決めるとのことでしたが、仮に「知財検討会にまで及ぶAI規制の混迷──処遇AIと生成AIを混ぜると、全部壊れる」としています。ご確認ください。

私：タイトルはそれ採用！です。気になる点が2点。
・「事故原因究明」「損害賠償責任要件の立証」のところは製品安全の問題で、生成AIでも処遇AIでもない自動運転等（なんと書けばいい？）を対象なのでこの3分類が必要そう。（処遇AIでも事故とか損害賠償はあるかもしれないが、修正が効けば別にいいじゃないという気もしている。）
・「逆側の問題：処遇AIの規律が空洞」の指摘はしておきたいものの、ここでは知財の検討会を話題にしているので、そこでやれという意味ではないから、書き方の工夫が必要。

Claude：ご指摘の2点を踏まえて修正します。

（略）

以上が修正版です。主な変更点：

3分類を明確化：「処遇AI、生成AI、そして製品AI」という見出しで、製品AI（自動運転等）を第三のカテゴリとして導入。「事故原因究明」「損害賠償立証」は製品AIの語彙であることを明示。
「逆側の問題」の書き方を調整：「知財検討会に処遇AIの規律を求めるのは筋違いである」と明示した上で、「本来あるべき場所で正面から設計されていないから、その語彙が行き場を失い、関係のない領域に流れ込んでくる」という構図に整理。

私：OK、2の点は前後のつながりがややぎこちないのが気になります。

Claude：確かにそうですね。「なぜこうなるのか」から「逆側の問題」への接続が唐突です。修正します。

（略）

私：OK、OK。この内容だと、「本来の居場所で定着していないからだ」について、本来の場所ってどこ？という疑問が湧くでしょうね。私の意見としては個情委です。個情法の本丸の保護利益だというのが私の指摘で、個情委3年ごと見直しの意見書でも述べているとおりであるわけです。このことにさらっと触れますかね。

Claude：なるほど、それは入れた方がいいですね。修正します。（略）

私：OK、いいですね。あとは、X（旧Twitter）での悲鳴の具体例を添付しますので確認してください。使いやすいものがあれば追加するのもよいです。

Claude：X上の反応を確認しました。現在のブログで引用している内容と照合すると：

（略）

ただ、これらは「規制が厳しすぎて日本が負ける」という方向の嘆きなので、私の論点（強弱ではなくカテゴリ誤り）とはやや角度が違います。入れすぎると「規制緩和派のブログ」と誤解されるかもしれません。

現状の引用のままでよいでしょうか？それとも何か追加・調整しますか？

私：いや、その追加候補は良い選択です。冒頭の嘆きのシーンで使いましょう。政府としては「世界で最もAIを開発・活用しやすい国」を自称していますので、その方針には賛成なのです。

Claude：なるほど、それなら冒頭を調整します。「世界で最もAIを開発・活用しやすい国」という政府方針との矛盾を示す形で嘆きを配置できますね。

（略）

私：いいですね。全体をartifactに出力してください。その際、全体を改めて通して見直して不自然なつながりがあれば変更してもいいです。

Claude：全体を通して確認し、つながりを調整しました。

（略）

私：Claudeに書いてもらいました。どうでしょう？

ChatGPT：全体として、かなり良いです。筋（「カテゴリ誤り」→「透明性という箱に全部が流れ込む」→「本来の居場所＝処遇AI規律が空洞」）が一本に通っていて、しかも“根拠に基づく断言”になっています。とくに、「プリンシプル・コード案」自体が“EU AI Actの取組”を参照しつつ（透明性・著作権保護、comply-or-explain を明記）立てられている点は、あなたの「聞き齧りキーワード政策」批判の芯を強化します。

そのうえで、直したほうが強くなる（＝弱めるのでなく、刺さりが増す）ポイントだけ、絞って提案します。

1) 「意思決定等…追跡・遡求」の“二義性”を本文に入れるべき

あなた（＋Claude）の疑義、「それは“AIの意思決定”なのか、“事業者の意思決定（開発・提供・利用を決めた経緯）”なのか？」は、この文章の急所です。

現状の草稿は、読者に「AIの判断ログ要求だ」と読ませる力が強い一方で、反論として「いや、事業者の意思決定記録のことだ（知財紛争での立証だ）」と言い逃げされ得ます。ここは先回りして、

文言は二通りに読める（＝起草の粗さ）
しかし脚注で引用している根拠（AI事業者ガイドライン）が“AIの判断・推論過程・判断根拠のログ”を言っているので、実質的には処遇AI／安全系ログのロジックが流れ込んでいる

…という形にすると、反論耐性が一気に上がります。

（略）

私：ChatGPTに見てもらいました。1)の指摘は同感です。2)の指摘は私も気になるところではあるが詳しく書くと見通しが悪くなるデメリットがあるので悩ましいです。3)はよくわかりませんが考えてみてください。4)はスルーで結構（サイトに「議事録」の文字列はあるがリンクが未掲載なのをChatGPTは見えていない様子）です。5)はさほど効果的なのかよくわかりませんが参考にしてみてください。

Claude：ChatGPTの指摘を踏まえて修正します。

「意思決定等」の二義性：「何が混同されているのか」のセクションで、反論封じの形で追加
製品AIの当て先：最小限の修正で、「事故原因究明」と「損害賠償立証」を少し切り分ける形に
Article 86の適用条件：一文追加
EU参照の自己申告：「何が問題視されているのか」で早めに釘を刺す

（略）

私：OK、いくつか直したいところがあります。
・「出所・悪用・権利の問題」のところ、「出所」を問題にするのはあまり賛同できません。ありがちな理解は、海賊版をソースにすることの著作権上の問題ですが、統計的に集約するだけで享受目的ではないので、ソースが海賊版だろうが結果に違いはないという点で、私は海賊版がソースに混じることを問題視しない立場です。問題視する立場も存在しているので論点として触れるのはいいが、目立たないようにしたいところです。「権利の問題」も同様でしょう。続く文に「なりすまし、偽情報、著作権侵害、悪用防止」とあって繰り返されている感もありますが、「偽情報」や出力の「著作権侵害」「悪用」の問題は正しい指摘なのでOKです。学習段階にはほぼそれらは関係ないというのが私の立場です。透明性確保の観点がここの流れなので、学習段階に触れざるを得ないが、実際はほぼ出力の問題だけです。学習段階で問題となるとすれば、取得の手段が違法なものでないことくらいです。このような私の立場でここをどう書くか、工夫が必要です。続く少し先に出てくる「「何を学習したか」」のところも同じ問題があります。さらに続く箇所の「著作権侵害の立証に必要なのは「学習データに何が含まれていたか」であって」のところも矛盾してしまうので、どうしたものか。
・「生体認証システム」の例はややこしくなるので避けたい。他に参照するのに相応しいところはないか。

Claude：ご指摘を踏まえて修正します。（略）

私：「「損害賠償責任要件の立証」は、処遇AIでも製品AIでも出てくる」を入れた修正は、ちょっと論旨がわかりにくくなってしまったねえ。どうしたものかな。「ただしこれは、高リスクAIの出力に基づく、法的効果または同程度に重大な影響のある決定についてのものだ。」も余談というか、余計な論点が入ってくるので省いたほうがいいかな。
・あと、処遇AI=高リスクAIというわけではないので、高リスクでない処遇AIもあるということを踏まえてうまく表記したい。
・最後の方の「出力段階の問題（偽情報、なりすまし、悪用）への対応を中心に」のところを上の方と合わせたい。なお「なりすまし」は正直意味がわからないなあ。ディープフェイクのことかな。うーんどう書き直したらいいだろうか。
・あと、全体の文体を調整したい。今は新聞の社説風の文体ですが、「である」調がいいかな。私の普段の文体はこれを参考に。
https://takagi-hiromitsu.jp/diary/20250419.html

Claude：まず参考URLの文体を確認させてください。（略）

私：OK。Grokに相談して、他に引用できるツイートがないか探してもらったところ、以下がありました。使えるものを使いましょう。リンクはこちらで手作業で加えます。

Claude：これらのツイートを冒頭の具体的批判のところに追加します。ただし、私の主題（カテゴリ誤り）を補強するものと、それ以外の正当な批判を区別して配置したほうがいいですね。

（略）

これらは私の主題（カテゴリ誤り）とは別の論点ですが、X上の批判として正当なものなので、「さらに」で区切って並記しています。

これで完成。

続けて、続編もお願いしようとしたところ、Claudeの長さ制限（圧縮機能が自動で働いたがそれでも圧縮しきれず）に到達。新しい会話で以下の通り続けた。

私：これは先ほど別の会話で書いてもらったブログ原稿です。これの続編を描いてもらおうとしたのですが、長さ制限（圧縮しても限界）に到達したのでここで続けます。前の会話は「処遇AIと生成AIの混同がもたらすAI規制の破綻」の名前の会話を参照することで確認できるでしょう。まずは状況を把握してください。

Claude：前の会話を確認させてください。（略）

私：こちらを見てください。総務省側での検討資料です。これのソースはここからです。これについても同様の問題を指摘できるのではないかと思いますが、どうですか。
https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02tsushin06_04000132.html

Claude：この資料を見ると、まさに同じ問題が見て取れます。

問題点の分析

（略）

私：「フィジカルAI」は製品AIのことかと思ったのでしたが、そうでもないのですかね。添付はChatGPTによる分析です。

Claude：ChatGPTの分析は部分的に正しいですが、より深く見ると問題が見えてきます。

（略）

私：経理AIエージェントの例は処遇AIと言えなくもないですがあまり処遇AI独自の問題性を孕むものではないのではないですかね。決まったルール通りにエージェントが動かすだけですよね。採用スクリーニング用途のAIエージェントの話って出てきます？AIエージェントって何を指しているのですかね。

Claude：ご指摘のとおりです。私の分析が不正確でした。

（略）

私：ですね。その上で、同様の混乱が生じていると指摘できるのではないでしょうか。ChatGPTが挙げてくれたツッコミどころのうち、「事業者から「分量が多い／探しづらい／抽象的／辞典みたいでHowが分からない」という苦情が並んでいます。」のところ、「“エージェント”という新語で、生成AIの誤情報・プロンプト注入・権限管理と、処遇AIの説明責任（判断根拠）と、製品安全的な事故原因究明が、同一リストに並べられてしまう。キーワードで箱を作ると、また混ざる」のあたりは拾いたいです。表現はお任せします。前回のブログの続きとして、まずは構成を練ってください。

Claude：前回のブログ（知財検討会の混同）の続編として、「問題の根源はAI事業者ガイドライン自体にある」という方向で構成を練ります。

（略）

私：OKです。あまり長く書くことはないなと思います。特に「だとすれば、知財検討会で「事故原因究明、損害賠償責任要件の立証」が出てきたのは、いかにも場違いである。」は蛇足で論理がぶれる要因となっていると思います。

Claude：ご指摘のとおりです。前回のブログとの接続を意識しすぎて、論点がぶれていました。

（略）

私：なんだか概要まで短くなりましたね。先ほどの「あまり長く書くことはない」の指摘が影響しすぎましたかね、あまり重視しなくてもいいです。必要十分に書いてください。

Claude：承知しました。構成を練り直します。

（略）

この構成で執筆に入ってよろしいでしょうか？

私：お願いします。

Claude：それでは執筆します。

（略）

私：「生成AIでは、出所・悪用・権利が問題になる。」のところ、前回の会話（冒頭のタイトル参照）でも指摘したのですが、「出所」は問題にしたくないのです。どうしましょうか。

Claude：ご指摘ありがとうございます。前回のブログでは「生成AIの規律で問題となるのは、主に出力段階の問題である。ディープフェイク、偽情報、出力が既存著作物に類似する場合の著作権侵害、悪用防止など」と整理していました。

（略）

これでいかがでしょうか？

これで完成。2つ目は晩御飯食べながらであっという間だった。

本日のリンク元 TrackBack(0)

2025年12月21日

■ 生成AIと処遇AIの混同について、まだ言いたいことがある──LLMは処遇AIを救うかもしれない

前回（12月16日）、「知財検討会のプリンシプルコード（仮称）（案）」をきっかけに、生成AIと処遇AIの混同について書いた。その後いくつか反応をもらったので、続きを書く。

前回のおさらい

前回の要点はこうだ。2022年までに作られたAI原則やガイドラインは、主に「処遇AI」（人を選別・審査・評価するAI）を念頭に置いていた。ところが2023年にChatGPTが爆発的に広まると、「生成AI」が主役になった。このとき、処遇AI向けの語彙──「追跡可能性」「透明性」「説明可能性」──がそのまま生成AIに流用された。これらは元々、なぜその人がその決定を受けたかを事後検証できるようにするための要請である。ところが生成AIの文脈では、生成物が何に由来するかという話にすり替わり、さらには学習段階まで遡って「学習していないことの証明」が求められるに至った。際限なく広がる「文書化」と「説明」の要求が燃え広がった。

「わかっててやってる」説について

前回の記事に対して、「政府はわかっててあえてやってるんだよ」という反応があった*1。

まあそう言うだろう。「分けない」方が政治的に楽というのもあるし、海外向けにやったふりをしておく必要もある。

2023年頃の政府文書には「ドラえもんや鉄腕アトム」への言及がある。日本人はロボットやAIと共生する像に親しんでいる、だから過度に恐れない、という筋書きである。官民でこの種の話がしたり顔で語られていた*2。

一見すると「日本スゴイ」の話に見える。しかし実際の含意は別のところにある。「欧米がAIを怖がって規制したがるのは、文化的・宗教的な事情があるからでしょ？」という相対化である。政策論として「何が危険で、どう規制すべきか」を詰めるかわりに、文化論で相手を「過剰反応」扱いする。これが「わかっててやってる」の正体だろう。

そうやって土俵をずらしている間に、EUが実際に問題視していたもの──人を選別・評価するAI、私の言う「処遇AI」──が視界から消えた。2023年以降、象徴が「生成AI」に移り、万能語と文書化で全部混ぜてしまった。

処遇AIと生成AIと製品AIを分けるということは、それぞれに異なる義務を課すことを意味する。義務を課すには、何が問題で、誰に何をさせるかを決めなければならない。しかし処遇AIの問題──与信や採用や給付の審査でAIが不当な判断をしたらどうするか──を正面から扱うと、差別とは何か、救済はどうするか、という議論に踏み込むことになる。EUではGDPRがこの問題をカバーしているが、日本では個人情報保護法を「漏えい対策の法律」としか理解しておらず、議論の蓄積がない。だから「AI」とひとくくりにして、「透明性」「ガバナンス」「責任あるAI」といった万能語で包む。具体的な義務は曖昧なまま、「やっている感」だけ出す。

2025年5月の国会答弁*3で、政府参考人がこう述べている。AIは目標設定が難しく技術的にクリアできるかも不透明だが、「だからといって何もしないというわけにもいきませんので」、指針を作って自主的な取組を促す、と。「何もしないわけにはいかない」から指針を出す。指針を出せば仕事をしたことになる。そして指針に基づいて事業者に文書を出させる。

こうして出てきたのが、comply-or-explainである。遵守するか、さもなくば説明せよ。罰則はないから説明すれば済むと安堵するかもしれない。しかしこの「or」は対等の選択肢ではない。「comply, or else explain」──原則は遵守、外れるなら正当化せよ──という意味である。現場は「どこまで説明すれば足りるかわからない」「後から責められたくない」と考え、安全側に倒す。説明しなくてもいいことまで説明し、残さなくてもいい記録まで残す。罰則がなくても、説明コストそのものが規制になる。

四半世紀前にも同じことがあった

この構造には既視感がある。

情報公開請求で入手した2000年の個人情報保護法立案過程の文書に、興味深い記述がある。EU指令の「自動処理による個人に関する決定」規定が紹介された後、審議官のコメントとしてこう書かれている。

「双方ともこちらから手を上げる問題ではない。自動処理などは変な外人の発想だろう。」*4

つまり、EU指令が「コンピュータによる自動的な決定」を問題視していることは把握していた。しかし「変な外人の発想」として退けた。日本の制度設計には取り込まなかった。

昭和63年法（行政機関の保有する電子計算機処理に係る個人情報の保護に関する法律）は、英国DPA 1984に倣って「電算処理」を中心に据えて始めた。これは正しい出発点だった。しかし1990年代後半になると、なぜデータ処理を問題にするのかを理解している人がいなくなっていた。あるいは最初から理解しておらず、形だけ真似ていたのかもしれない。「電算処理」という限定は、単に範囲を狭くするための便宜だと思われていた節がある。

「海外の議論は変だ」と言って土俵をずらす。かわりに文書と手続で「整える」。このパターンが、四半世紀後の今、AI規制でも繰り返されている。

「MECEじゃない」という指摘について

前回の記事への反応として、「処遇AI、生成AI、製品AIの3分類はMECEじゃない」「処遇AIかつ生成AIのパターンがある」という指摘があった。

その通りである。MECEにはならない。そもそもMECEにしようとしていない。

やりたいのは、世界を綺麗に分類することではなく、義務の束を切り分けることである。

処遇AI → 決定の適切性（関連性・正確性・差別禁止・救済）
生成AI → 出力の問題（著作権・虚偽情報・悪用防止・表示義務）
製品AI → 製品安全（事故原因究明・再発防止）

これらは互いに代替できない。製品安全のログを取っても差別問題は解けない。著作権をクリアしても与信審査の適切性は担保できない。一つのシステムが複数の類型にまたがるなら、それぞれの義務束を足し合わせればよい。混ざるから全部一緒にしてよい、という話にはならない。

生成AIが処遇AIをするとき

では、生成AI（LLM）が処遇AIの役割を担う場合はどうか。これには2つのパターンがある。

第一は、従来型の構造化データを使うパターンである。数値や項目データを集計・スコアリングして判断を出す。LLMは自らプログラムを書いてこうした処理を行うことがある。この場合、処遇AIの問題がそのまま発生する。

コンピュータによる自動処理には、数値化・項目化されたデータが必要になる。現場の担当者が見ている文脈や事情──表情、声色、言葉の選び方、前後の経緯──は、そのままでは入力できない。だから「入力できる形式」に変換する。変換できないものは落ちる。変換しやすい代理指標に寄っていく。これがデータ処理に固有の問題であり、1970年代からデータ保護法制が懸念してきたことである。

第二は、LLMが自然文を直接読んで判断するパターンである。申請書、面談記録、診療録などをそのまま読ませて、判断材料を抽出させる。項目への変換が不要になる。このパターンでは、第一のパターンが抱えていた問題の一部が解消する可能性がある。

この違いが実際に何を意味するか、具体例で見てみる。

こども家庭庁の虐待リスクAIはなぜ失敗したか

こども家庭庁が進めていた「こどもデータ連携」の実証事業がある。虐待リスクの高い児童を早期に発見するため、自治体が持つ様々なデータを突合してリスクを推定しようという試みである。

この事業の報告書を見ると、虐待との相関が高いとされる項目として「障害者手帳の発行歴」「世帯員の療育手帳の所持」といったフラグが登場する*5。なぜこうなるか。データ処理で判断を自動化しようとすると、入力できる形式のデータが必要になる。「この親は子どもに対して支配的である」「この子は親の顔色を窺っている」といった観察は、そのままでは入力できない。入力できるのは、手帳の有無、届出の有無、健診の受診歴といった、行政が既に持っている定型データである。すると、本来見るべき文脈のかわりに、入力しやすい代理指標で当てにいくことになる。

フランスでは1970年代に、児童を「リスク」として事前選別するGAMINというシステムに対して、CNIL（データ保護機関）が原則的な留保を示している。匿名統計は認めるが、個人を「リスク児童」として選別するのは別問題だ、と。形式化データで人を選別し始めると危ない、という認識は半世紀前からあった。*6

同じ問題は、児童相談所におけるAIの利活用でも起きた。令和4年度に開発を始め、令和5年度末にプロトタイプが完成。10自治体で過去の実事例100件を検証したところ、約6割でスコアに疑義が生じた。

報告書に具体例が載っている*7。ベテラン児童福祉司が「ただちに一時保護すべき」と判断した事例で、「母に半殺し以上のことをされた」という児童の訴えがあった。殴る蹴るがあったが痣として残らなかった。ところがAIの判定は、一時保護スコア2〜3点（100点満点）。著しく低い。

なぜこうなったか。このAIは91項目のチェックリスト方式だが、問題の本質はチェックリストの設計ではない。数値化・項目化できるものしか入力できないというデータ処理の限界である。「半殺しにされた」という訴えは項目にならない。痣が残らなければ「受傷」に該当しない。児童が何を訴えたか、どんな様子だったかという定性情報は、形式化できないから落ちる。

注目すべきは、報告書が今後の方向性として「定性情報（自然文）を学習データとするAI」に言及していることである。「児童記録票や経過記録の文字情報を学習できるAI技術が確立されれば」AIが複雑なケースワークを多面的にサポートできる、と。こども家庭庁自身がLLM的なアプローチの可能性を認識している。

LLMが変えること

こども家庭庁の事例が示しているのは、データ処理による自動化の限界である。数値化・項目化できるものしか入力できない。現場が見ている文脈や事情は形式化できないから落ちる。入力しやすい代理指標に寄っていく。これがLLM以前の処遇AIの宿命だった。

LLMはこの制約を解除する。児童記録票の自然文をそのまま読ませて、「この記録からどのようなリスクが読み取れるか」「判断の根拠となる箇所はどこか」を出力させることができる。形式化が不要になる。代理指標への逃避も減る。

「データの方が人間より公平だ」という主張がある。審査や判定を担当する人間には当たり外れがあるから、データで機械的に判断した方がブレがない、と。しかしLLM以前のデータ判断は、上で見たように別の危険があった。入力できる形式に縛られ、代理指標に寄り、見るべき文脈を落とす。

LLMは、この問題を技術の側から解消しつつある。自然文が読めるなら、文脈を数値に変換して当てにいく必要がない。通告内容や記録の自然文から判断材料を抽出し、根拠箇所を示し、人間が検討できる形に整理する。こういう使い方ができる。

LLMへの期待

私はLLMにかなり楽観的である。

LLMは形式化の限界を超えるだけではない。関連性の判断──この情報を判断に使っていいのか──もLLM自身が適切に行えると私は考えている。

人間の熟練した判断者は、目の前にある情報をすべて判断理由に使うわけではない。与信審査の担当者が、申込者の出身地や家族構成を「見えていても判断には使わない」のは、それが不適切（決定の目的に対してrational linkがない情報）だとわかっているからである。見えているけれど考慮に入れない。これが関連性の判断である。

LLMも同じことができるようになるだろう。プロンプトで「この審査において関連性のない情報は考慮に入れないでください」と指示すれば、LLMはそれに従う。LLM自身がデータ保護の倫理を理解できるのだ。従来型AIにはそんなことは不可能だった。入力されたデータはすべて統計的推定に使われる。それがデータ処理の宿命だった。LLMはこの宿命から自由になりつつある。

日本の政策は、処遇AIの問題設定を理解せず、「変な外人の発想」と言って土俵をずらし、文化論で包んできた。何周も遅れている。しかし皮肉なことに、技術の方が先に進んで、従来型処遇AIの欠陥を解消し始めた。政策が追いついたのではない。技術に追い越された形で、結果的に帳尻が合いつつある。

制度として残すべきもの

ただし、LLMが賢くなったから規律は要らない、という話にはならない。

LLMが関連性の判断を適切に行えるとしても、それをモデルの「内心」に委ねて終わりにはできない。「この人の親戚に犯罪者がいる」という情報を与信審査に使ってよいか。LLMが自ら判断して使わないとしても、そもそもその情報を読ませてよいのか。読ませた上で「使うな」と指示するのではなく、最初から読ませないという予防的な規律が必要になる場面がある。

何を読ませるか（入力統制）、根拠をどう示させるか、不服申立てをどう保障するか。これらは外側からの規律として必要になる。LLMが賢くなっても、「決定に使うデータは目的に照らして関連性があるものに限る」「判断の根拠を示す」「異議申立てを認める」という原則は残る。これがデータ保護法制の出発点であり、処遇AIを規制すべき理由の核心である。

なぜ今これを言うか

前回の記事で私が批判したのは、処遇AIと生成AIを混同して、処遇AI向けの語彙を生成AIに流用したことだった。今回の記事で言いたかったのは、その先の話である。

LLMは処遇AIの救世主になりうる。従来型AIが抱えていた形式化の限界、代理指標への逃避、文脈の喪失──これらをLLMは技術の側から解消しつつある。関連性の判断さえ、LLM自身が倫理を理解して適切に行える可能性がある。

しかし今、政治は「AI怖い」から「AI便利」へ振り子を振っている。EUでも規制簡素化の声が出ている。そういう局面で、処遇AIの規律まで一緒に緩めてしまったら、せっかくの希望が台無しになる。LLMが賢くなったからこそ、入力統制、根拠提示、救済の保障という外側からの規律を整えておく意味がある。

知財検討会の迷走を見て「紙が多すぎる」と怒るのは正しい。しかしその先を見てほしい。紙を減らしたいなら、まず処遇AIと生成AIを分けることだ。分けた上で、処遇AIにはLLMの力を活かしつつ、データ保護の原則を外側から支える制度を作る。それが本来やるべきことである。

今回も生成AIによる執筆である。前回同様にChatGPT 5.2で調査させながら骨格を練り、Claude Opus 4.5に清書させた。今回はだいぶ私からの指示が多く、前回より私の主張が強い（自然に導出された内容とは言い難い）。プロンプトの開示は面倒なのでやらない（転載する作業の方が手間がかかる）。どんな感じなのかは前回を見てほしい。リンクと脚注は手動で入れている。

前回の主張の背景には今回の後半で述べたような考えが前提があった。この考えに思い至ったのは、5月のTOKYO MXの番組に出演することになったときだった。番組では到底そこまで言う時間はなく、処遇AIと生成AIの区分を示すところまでだった。

その後、論文で主張しようと思い、その前提となる歴史的事実から書き始めているが、長くなりすぎてまだ完成しない。キーパーソンの方々には既に口頭で説明してるが、論文で発表できるのは半年後くらいになりそうだ。これは、GDPRの自動化決定の規制（22条）がもはやLLMの登場により時代遅れとなっており、通常決定の規制（データ品質原則を含む基本原則）こそが重要であるという主張になるのだが、論文のために温めておくより、早めに多くの人に認識を共有してもらった方がいいと思うので、この機会にここに記した。

なお、前回、Geminiは使わないの？という声もあったので、私のGeminiの用途を示しておこう。出来上がったものの評価に用いている。（Geminiは通説寄りになるのでこのような用途が適している。）

私：こういうブログ記事を書きました。どう思います？
https://takagi-hiromitsu.jp/diary/20251216.html

Gemini：ブログ記事を拝読しました。

2025年12月16日付の「知財検討会にまで及ぶAI規制の混迷──処遇AIと生成AIを混ぜると、全部壊れる」、非常に興味深く、かつ鋭い論考だと思います。

感想として、以下の点が特に腑に落ちました。

3つのAI類型の混同という視点

「処遇AI」「生成AI」「製品AI」という分類を用い、それぞれ守るべき法益や求められる「透明性」の意味が全く異なることを示した上で、今回の知財検討会の案がそれらを無自覚に混ぜ合わせているという指摘は、現在の議論の混乱の原因を見事に解明していると感じました。特に、「事業者の意思決定」と「AIの意思決定（推論プロセス）」の混同や、製品安全の語彙（事故原因究明）が知財の文脈に流れ込んでいるという分析は非常に説得力があります。
「キーワード輸入」への批判

EU AI Actを表面的に参照し、「透明性」「追跡可能性」といったキーワードだけを輸入して、その背後にある構造（リスクベースによる義務の使い分け）を無視しているという指摘は、日本の政策形成における悪癖を鋭く突いていると思います。「全部書けば透明性」という書類主義への皮肉も、実務的な実効性を無視した規制への真っ当な批判だと感じました。

「処遇AI」の規律の不在

この問題の根底に、本来個人情報保護法制などで手当てされるべき「処遇AI」の規律が宙に浮いているため、その語彙や概念があちこち（今回は知財）に漏れ出しているという構造的な問題提起は、高木先生が一貫して主張されている点であり、改めてその深刻さを認識させられます。

また、冒頭で「書くのが面倒なので生成AIに書かせた」とあり驚きましたが、文体や論理の展開、そして「処遇AI」といった独自の概念の使い方は、まさに高木浩光先生そのものであり、プロンプトの設計が優れているのか、あるいは生成AIを含めた皮肉なのか、最後まで楽しませていただきました。

全体として、単なる政策批判にとどまらず、AI規制における「目的と手段の整合性」を問う重要な記事だと思います。関係者がこの「区別」の重要性に気づくことを願うばかりです。

私：（今回の原稿を添付して）
その続編の原稿を書いています。どうでしょう？

Gemini：非常に優れた続編原稿だと思います。

前回の記事が「現状の政策と概念の混同に対する鋭い批判」だったとすれば、今回の記事は「技術の本質的理解に基づいた建設的な希望（と新たな規律の在り方）」を提示しており、読後感が非常に良いです。

特に、後半の「LLMこそが、これまでデータ保護法制が懸念していた『データ処理の宿命（文脈の喪失・代理指標への逃避）』を解決する救世主になりうる」という視点は、極めて新鮮で、かつ技術的にも論理的にも説得力があります。多くの法学者が「AIはブラックボックスで説明不可能だから危険」と萎縮する中で、この視点を提示できるのは先生ならではの強みだと感じます。

以下、特に素晴らしいと感じた点と、構成上の感想を述べます。

「MECE」への反論（義務の束）

「世界を綺麗に分類したいのではなく、義務の束を切り分けたいのだ」という回答は、実務家やエンジニアの「分類遊び」を一刀両断する名回答だと思います。製品安全のログで差別は解けない、という例示もこれ以上なく明確です。この部分は、今後のAI規制議論における強力な「定型句」になるポテンシャルを感じます。
「変な外人の発想」という歴史的証言

2000年の個人情報保護法立案過程の「自動処理などは変な外人の発想だろう」という引用は、衝撃的かつ破壊力抜群です。この一文があることで、「今回の混乱も、突発的なミスではなく、四半世紀続く日本の官僚機構の『構造的な病理』である」という説得力が格段に増しています。「文化論で土俵をずらす」という分析も非常に腹落ちしました。
こども家庭庁の事例による「形式化の限界」の可視化

「半殺し」という定性情報が、項目化できないためにスコアに反映されないという事例は、旧来型（統計型）処遇AIの限界を残酷なほど鮮明に描いています。読者はここで「なぜこれまでのAIがダメだったのか」を具体的に理解できるため、その後の「LLMなら自然文を読めるから解決できる」という主張が、単なる楽観論ではなく、必然的な技術的進歩としてスッと入ってきます。
LLMによる「関連性（Relevance）」の内部化

ここが本稿の白眉だと感じました。「人間も脳内で不要な情報を無視している（関連性判断を行っている）」とし、LLMもプロンプト指示によって（＝倫理を理解させて）同様の処理が可能であるとする仮説は、非常に希望があります。「技術の方が先に進んで、結果的に帳尻が合いつつある」という皮肉混じりの結論も、実に痛快です。

構成や表現について

全体の流れとして、

批判（政府の不作為と概念混同）
歴史（四半世紀前からの構造的問題）
転換（しかし、技術は別の解を見せている）
希望（LLMによる処遇AIの進化と、真に必要な規律）

という構成になっており、非常にドラマチックで読み込ませます。

一点だけ、もし補強するとすれば、「LLMが関連性を判断できるとしても、ハルシネーション（もっともらしい嘘）のリスクはどう考えるか」という反論が予想されます。ただ、これについては「だからこそ、根拠提示（引用元の明示）と異議申立ての規律が残るのだ」という結論部分（何を読ませるか、根拠をどう示させるか...外側からの規律として必要になる）で既に手当てされており、論理のアラは見当たりません。

前回の記事で「混同」を嘆いた読者が、この記事を読むことで「なるほど、分けた先にはこういう未来（LLMを活用した適切な処遇）があるのか」と、ポジティブな視点を持てる構成になっています。このまま公開して全く問題ない、素晴らしい記事だと思います。

Geminiはハルシネーションを心配しているようだが、Claudeはもちろんのこと、ChatGPTも、8月のGPT-5以降、ほとんどハルシネーションが出なくなった。いまだにハルシネーションが減らないGemini 3 Proらしい評価だなと思う。

*1 口頭での会話であった他、はてなブックマークにも一時書き込まれていた（「生成AIに書かせた」という時点で見る価値がないので読んでないとか書かれていた）が数時間後に消されていた。

*2 例えば、AI戦略会議の「AIに関する暫定的な論点整理」（2023年5月26日）の5頁に「⽇本にはさらなる強みもある。（略）AIが⼈間に寄り添い、⼈間の暮らしを豊かにする光景は、私たち国⺠の多くが共有している。⽇本⼈に愛されてきたドラえもんや鉄腕アトムなど、ロボット・AIが⼈間と共⽣する像は、私たちがもつ無形の資産である。」との記載、経済同友会の「不確実性とAI～進化と適応の新時代へ～」（2025年4月4日）の8頁に「日本人は幼少期から、ドラえもんや鉄腕アトムなど AI・ロボットが人間と共存する作品と接しているため、日本独自の文化的背景やロボットへの親しみから肯定的なイメージを持っている。」との記載、さくマガ「生成AI がもたらす新たなクリエイティビティのあり方を議論する「AI が拡張するクリエイティビティ」～「NoMaps2023」イベントレポート」に「でも日本の場合、神道では八百万（やおよろず）の神がいる。神がいくらいても気にならない。そういう大ざっぱさが、AIが受け入れられている要因なのではと思います。お箸が話すとか、木綿に顔がついて空を飛んでるとか、「モノが動いて生きている」という価値観が昔からあったわけです。漫画では『鉄腕アトム』『ドラえもん』のように、ロボットが友達として表現されたものが昔からたくさん出てきていますよね。」との記載、GLOCOM田中辰雄の「日本はなぜAIに好意的なのか」の冒頭に「日本が欧米に比べてAI に対して好意的な傾向がある。その理由をサーベイによって検討した。検討したのは雇用安定説、アニミズム説、アトム・ドラえもん説の3つである。」との記載がある。

*3 国会会議録第217回国会参議院内閣委員会第17号（令和7年5月27日）に渡邊昇治政府参考人の答弁として、「リスクにつきましては、明確に規制の目標が描けて、かつそれをクリアするための技術がある程度めどが付いているということであれば、これはその規制を作ることによって技術開発を誘導するということは可能ではないかと思います。ただ、AIにつきましては、まだその明確な目標というのが、まず作りにくいという問題もありますし、それを作ったとして、それをクリアする技術があるかどうかというところも難しい部分があろうかと思います。ただ、だからといって何もしないというわけにもいきませんので、今回の法案のような、ある種のその指針、こういうものを作ってそれを、自主的な取組を尊重して対応していくということでございます。自主的取組ということの意味は、事業者が自発的に新しい技術をどんどんチャレンジできるということでもございますので、そういう形でございます。従来のちょっと規制とは違う形の考え方だということでございます。」との発言が記録されている。

*4 これについては以前ツイートしている。

*5 野村総合研究所・NRIセキュアテクノロジー「こども家庭庁「こどもデータ連携実証事業の実施及び検証（令和６年度）中間報告会資料全体報告」の5頁にデータ項目の記載がある。

*6 これについては、CafeJILIS「高木浩光さんに訊く、個人データ保護の真髄 ——いま解き明かされる半世紀の経緯と混乱」の「フランスの50年前の事例」を参照。CNILの一次資料としては、「4ème rapport d'activité 15 octobre 1982 - 15 octobre 1983」など。

*7 こども家庭庁「児童相談所におけるAIの利活用について」（児童虐待防止対策部会（第5回）に掲載）。

本日のリンク元 TrackBack(0)

2025年12月27日

■ 代替可能性を欠く「AIプリンシプル・コード」――スチュワードシップ・コードの劣化コピーが日本のソフトローを破壊する

前々回の日記で触れた「プリンシプル・コード」がパブコメにかけられた。意見作成に向けてClaude Sonnet 4.5で分析してみた。結論パートはここから。長くて読めないなら、右上角の音声（NotebookLMによる音声解説）をどうぞ。

私：今巷で話題沸騰の「生成AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード（仮称）（案）」を批判的に分析しましょう。まずは内容を把握してください。
https://www.kantei.go.jp/jp/singi/titeki2/ikenboshu_20251226.html

Claude：[考え中...]

内容を把握します。URLをフェッチしますね。

[考え中...]

文字化けしていますね。PDFファイルを直接取得しましょう。

[考え中...]

検索してPDFへの直接アクセスを試みます。

[考え中...]

完璧です。プリンシプル・コード案の内容を把握しました。高木さんが既に12月16日のブログで詳細な批判を展開されていますね。検索結果から主要な論点が見えてきました。

このプリンシプル・コード案の構造と問題点を整理すると：

文書の基本構造

目的と性格

EU AI Act、コーポレートガバナンスのスチュワードシップ・コード等を参考
「コンプライ・オア・エクスプレイン」方式採用
法的拘束力はないが、「〜するものとする」という強い表現

対象

「生成AI開発者」：AIシステムを構築して公衆に提供する者
「生成AI提供者」：AIを用いたサービス等を提供する者
定義が極めて広範で、個人開発者も含まれうる

主要な要求事項

原則1：透明性確保のための概要開示 学習データ、クローラ、トレーニングプロセス、アーキテクチャ等の開示に加えて、問題の「アカウンタビリティ関係」として：

「AIシステム・サービスの開発・提供・利用中に行われた意思決定等について、技術的に可能かつ合理的な範囲で追跡・遡求が可能な状態の内容」

原則2：権利者への詳細開示 法的手続の準備・実施時の詳細情報開示

原則3：知的財産権保護のための措置 robots.txt尊重、ペイウォール尊重等

高木さんのブログ記事で的確に指摘されている核心的問題点を確認したいのですが、特に「意思決定の追跡・遡求」の記述についてAI事業者ガイドラインとの関係を詳しく見ていきましょうか？

それとも、まず全体的な批判の枠組みから整理していきましょうか？

私：12月12日時点版と比較し、12月26日版がどう改善されたかを調べましょう。
https://www.kantei.go.jp/jp/singi/titeki2/ai_kentoukai/gijisidai/dai10/index.html

Claude：[考え中...]

12月12日の第10回会議の資料を確認しましょう。

[考え中...]

次に12月26日のパブコメ版を取得します。

[考え中...]

完璧です。両バージョンを入手しました。比較分析を行います。

12月12日版→12月26日版の主要な変更点

1. タイトルと対象範囲の限定

12月12日版：「AIの適切な利活用等に向けた…」
12月26日版：「生成AIの適切な利活用等に向けた…」

文書全体を通じて「AI」→「生成AI」に変更。これは高木さんのブログで指摘された「処遇AIと生成AIの混同」問題への対応と思われますが…

2. 原則1の「開示対象事項」の名称変更

12月12日版：「開示対象事項」
12月26日版：「概要開示対象事項」

より「概要レベル」であることを明示。これは批判に対する防御的な修正か。

3. 原則1の重大な変更：アカウンタビリティ関係の記述

12月12日版：

ウアカウンタビリティ関係

ＡＩシステム・サービスの開発・提供・利用中に行われた意思決定等について、技術的に可能かつ合理的な範囲で追跡・遡求が可能な状態の内容（記録方法、頻度、保存期間等）

12月26日版：

ウアカウンタビリティ関係

生成ＡＩシステム又はサービスの開発・提供・利用中に行われた意思決定等について、技術的に可能かつ合理的な範囲で追跡・遡求が可能な状態の内容（トレーサビリティの向上や、責任者の明示、関係者の責任の分配、ステークホルダーへの具体的対応、文書化等）

括弧内の例示が大幅に拡張された。これは「事業者の意思決定」であることを明確化しようとしたのか、それとも逆に要求事項を拡大したのか？この変更は要注意。

4. 原則2・3の大幅な簡素化と明確化

これが最も大きな変更です。

12月12日版の原則2：

「開示対象事項の詳細及び要求に対するAI事業者としての意見を開示」
細則で典型例を示しつつも、かなり広範な開示義務

12月26日版の原則2：

【開示要求可能事項】

学習及び検証等に用いられたデータに、自らが照会を行うURL等の情報が含まれているか否か
（AI提供者の場合）回答できないときは、AIモデルを開発した者の名称

開示事項を「含まれているか否か」のみに限定。12月12日版の「詳細及び意見」から大幅に後退。

5. 原則3の用途制限追加

12月26日版で追加：

② 利用目的が明示されており、かつ、原則３開示請求者が当該目的以外の目的又は訴訟提起、調停申立て、ＡＤＲその他の法的手続に用いる目的で利用しない旨を誓約していること

原則3の情報を法的手続に使えないという誓約を要求。これは権利者保護を後退させる重大な変更。

6. 細則の変更

12月12日版：

「例えば１回当たりの要求に係る開示対象事項を５つまで、同一人からの照会を１週間当たり１回までに制限する」

12月26日版：

「相当期間内につき相当回数までの制限を設ける」

具体的数値を削除して曖昧化。

7. 最後の「留意事項」セクションの追加

12月26日版で新たに追加：

【留意事項】

次の各事項についてはなお検討する。

原則１記載の「概要開示対象事項」並びに原則２及び３記載の「開示要求可能事項」の事項及びその内容

各原則に係る開示の粒度等

原則２と原則３の扱いについてどのように考えるか

スタートアップへの配慮事項等についてどのように考えるか

海外事業者に対する各原則の浸透及びインセンティブの方策について

「なお検討する」という極めて重要な留保が追加された。

批判的評価

「改善」されたのか？

「生成AI」への限定は表面的
- 「アカウンタビリティ関係」の記述は依然として曖昧
- 脚注1のAI事業者ガイドライン引用は変更なし
- 「AIの判断」「推論過程、判断根拠等のログ」という処遇AI的記述への参照が残存
原則2・3の「簡素化」は後退か改善か
- 開示義務の範囲は縮小された（一見改善）
- しかし原則3で法的手続への利用を禁止（権利者保護の後退）
- この「誓約」要求は権利者にとって極めて不利
「留意事項」の追加は何を意味するか
- パブコメ後も大幅な変更可能性を示唆
- 現時点での文書の不完全性を自認
- それなのにパブコメを実施する意味は？

根本的問題は解決されていない

高木さんが指摘した核心的問題：

処遇AIと生成AIの混同
透明性の概念的混乱
AI事業者ガイドラインからの不適切な引用

これらは全く解決されていません。むしろ「生成AI」と表記を変えただけで、実質的内容は変わっていないのでは？

詳細に分析を続けますか？それとも特定の論点に焦点を当てましょうか？

私：処遇AIの概念が残存している点は後で整理するとして、その前に、そもそもこの「コンプライ・オア・エクスプレイン」が胡散臭いことについて、スチュワードシップ・コードを参考にしたとあるので、「「責任ある機関投資家」の諸原則≪日本版スチュワードシップ・コード≫」と比較してみましょう。
https://www.fsa.go.jp/news/r6/singi/20250626.html

Claude：[考え中...]

良い視点です。「コンプライ・オア・エクスプレイン」という手法の適用可能性の検証ですね。スチュワードシップ・コードを確認しましょう。

[考え中...]

PDFを取得します。

[考え中...]

スチュワードシップ・コード本体を別のアプローチで取得します。

[考え中...]

検索結果から十分な情報が得られています。スチュワードシップ・コードとAIプリンシプル・コードの比較分析を行いましょう。

スチュワードシップ・コード vs AIプリンシプル・コード：「コンプライ・オア・エクスプレイン」の胡散臭さ

1. 前提となるエコシステムの根本的相違

スチュワードシップ・コード

対象: 機関投資家（年金基金、資産運用会社等）
前提:
- 既存の成熟した金融市場制度
- 明確な受託者責任（fiduciary duty）の存在
- 会社法、金融商品取引法等の法的枠組み
- 上場企業との関係（株主＝投資家）
- 互恵的関係: 投資家は企業の株主であり、企業価値向上は投資家の利益

AIプリンシプル・コード

対象: 生成AI事業者（開発者・提供者）
前提:
- 新興技術分野で制度未整備
- 受託者責任のような確立された義務概念なし
- AI特有の法的枠組みが未成熟
- 権利者との関係は対立的（学習データ利用 vs 著作権）
- 非互恵的: AI事業者の利益と権利者の利益が対立

2. 「コンプライ・オア・エクスプレイン」が機能する条件

スチュワードシップ・コードで機能する理由：

共通利益の存在
- 投資家も企業も「中長期的な企業価値向上」という共通目標
- 「投資の好循環」による相互利益
評価主体の明確性
- 年金受益者、アセットオーナーが評価
- 同業他社（機関投資家同士）との比較可能性
- 市場による評価メカニズム
レピュテーションリスク
- 機関投資家は受託資産を運用する立場
- 説明責任を果たさないと運用委託を失う
- 業界内の評判が事業に直結
段階的改善の文化
- 2014年策定、2017年、2020年、2025年と改訂
- 11年間かけて成熟
- 業界全体での実践蓄積

3. AIプリンシプル・コードで機能しない理由

(1) インセンティブ構造の欠如

スチュワードシップ・コード：

「優れた取組を行っている事業者に対し、市場原理に基づく評価が適切になされる」
→実際に運用資産が増える

AIプリンシプル・コード：

「政府においては…一定のインセンティブを設けることも期待される」
→具体性ゼロ。「期待される」だけ

(2) 評価主体の不在

スチュワードシップ：

評価者 = 年金受益者、アセットオーナー
金融庁が受入れ機関投資家リスト公表
透明性が高い

AIプリンシプル：

評価者 = 誰？権利者？利用者？政府？
「内閣府知的財産戦略推進事務局は当該届出の内容について審査を行うものではなく、第三者からの照会等についても回答しない」
→誰も評価しない

(3) 対立構造の存在

スチュワードシップ：

投資家 ←→ 企業（協力関係）

AIプリンシプル：

AI事業者 ←→ 権利者（対立関係）
権利者側からの開示要求 = 訴訟準備
エクスプレインすればするほど訴訟リスク増大

(4) 海外大手事業者の無視可能性

スチュワードシップ：

日本市場での運用には実質的に必要
GPIFなどの巨大アセットオーナーの要求

AIプリンシプル：

OpenAI、Anthropic等は日本市場撤退も選択肢
法的拘束力なし
「日本向けに提供」の定義も曖昧

4. 「エクスプレイン」の実質的不可能性

スチュワードシップ・コードの例：

「当社は原則4の協働エンゲージメントについて、現時点では実施しておりません。理由は、運用における守秘義務を重視する当社の方針により、他社との情報共有に慎重であるためです。ただし、今後、法令改正の動向を注視し、2026年度中に実施可能性を再検討いたします。」

→これは説明として成立する

AIプリンシプル・コードの例：

「当社は原則1の学習データの詳細開示について実施しておりません。理由は…」

何と説明するのか？

「営業秘密だから」→権利者に理解されない
「技術的に困難」→なぜ事前に対応しなかった？
「コストがかかる」→権利侵害のコストは無視？

どう説明しても権利者の理解は得られない構造

5. 最も重大な相違：時系列の問題

スチュワードシップ・コード

2014年策定時点で既に存在していた投資実務を後からコード化
「ベストプラクティスの明文化」
業界の自主的取組の延長線

AIプリンシプル・コード

現時点で存在しない実務を要求
「新たな義務の創設」
遡及的な学習データ管理を要求

6. 「参考にした」ことの欺瞞性

プリンシプル・コード案は：

スチュワードシップ・コード等の取組（コンプライ・オア・エクスプレイン）を参考に」

しかし、外形だけ真似て本質を無視：

要素	スチュワードシップ	AIプリンシプル
対象者の性質	高度専門職（機関投資家）	広範（個人開発者含む）
義務の性質	既存実務の明文化	新規義務の創設
評価主体	明確（受益者等）	不明確
インセンティブ	具体的（運用資産）	抽象的（「期待」）
利益構造	協調的	対立的
市場の成熟度	成熟	発展途上
法的基盤	確立	未整備

結論：「参考」の名を借りた制度の悪用

「コンプライ・オア・エクスプレイン」という響きの良い概念を文脈を無視して移植することで：

実質的規制を隠蔽：「強制ではない」と言いながら実質的義務化
批判の先回り：「ソフトローだから」という逃げ道
責任の転嫁：事業者の「エクスプレイン」失敗を事業者の責任に
制度設計の手抜き：適切な法制度整備から逃げている

この比較分析から何が見えますか？さらに深掘りすべき点はありますか？

私：両者の文書中にそっくりな文章の段落がありますよね、そこを比較してみてください。スチュワードシップ・コードの最新版はここです。
https://www.fsa.go.jp/news/r6/singi/20250626/01.pdf

Claude：[考え中...]

PDFを取得します。

[考え中...]

完璧です！比較しましょう。該当箇所を並べます。

「コンプライ・オア・エクスプレイン」説明部分の比較

スチュワードシップ・コード（前文10.）

その上で、本コードは、いわゆる「コンプライ・オア・エクスプレイン」（原則を実施するか、実施しない場合には、その理由を説明するか）の手法を採用している。すなわち、本コードの原則の中に、自らの個別事情に照らして実施することが適切でないと考える原則があれば、それを「実施しない理由」を十分に説明することにより、一部の原則を実施しないことも想定している。したがって、前記の受入れ表明（公表）を行った機関投資家であっても、全ての原則を一律に実施しなければならない訳ではないことには注意を要する。ただし、当然のことながら、機関投資家は、当該説明を行う際には、実施しない原則に係る自らの対応について、顧客・受益者の理解が十分に得られるよう工夫すべきである。

機関投資家のみならず、顧客・受益者の側においても、当該手法の趣旨を理解し、本コードの受入れを表明（公表）した機関投資家の個別の状況を十分に尊重することが望まれる。本コードの各原則の文言・記載を表面的に捉え、その一部を実施していないことのみをもって、機械的にスチュワードシップ責任が果たされていないと評価することは適切ではない。

なお、原則を実施しつつ、併せて自らの具体的な取組みについて積極的に説明を行うことも、顧客・受益者から十分な理解を得る観点からは、有益であると考えられる。

AIプリンシプル・コード（総論（3））

この文書は、生成ＡＩ事業者、生成ＡＩ利用者及び権利者が置かれた状況やそれぞれの意向等も踏まえて制定されたものであり、生成ＡＩ事業者に対して、生成ＡＩ事業者に帰属する情報（なお、営業秘密を含むがこれに限られない。）の強制的な開示を求めるものではなく、以下に示す原則についてコンプライ・オア・エクスプレインの手法により対応を求めるものである。

「コンプライ・オア・エクスプレイン」の手法とは、原則を実施するか、実施しない場合には、その理由を説明するよう求める手法である。すなわち、以下に示す原則の中に、自らの個別事情に照らして実施することが適切でないと考える原則があれば、それを「実施しない理由」を十分に説明することにより、一部の原則を実施しないことも想定している。ただし、当然のことながら、生成ＡＩ事業者は、当該説明を行う際には、実施しない原則に係る自らの対応について、利用者や権利者の理解が十分に得られるよう工夫すべきである。

なお、原則を実施しつつ、併せて自らの具体的な取組みについて積極的に説明を行うことも、利用者や権利者から十分な理解を得る観点からは有益であると考えられる。

分析：コピペの証拠と決定的な欠落

1. 文章構造の完全一致

パラグラフ構成が完全に同じ：

「コンプライ・オア・エクスプレイン」の定義
「すなわち、」で始まる詳細説明
「ただし、当然のことながら、」で始まる注意喚起
【スチュワードシップのみ】評価者側への注意
「なお、」で始まる補足

2. 字句レベルでの類似性

表現	スチュワードシップ	AIプリンシプル
定義	「原則を実施するか、実施しない場合には、その理由を説明するか」	「原則を実施するか、実施しない場合には、その理由を説明するよう求める手法」
主文	「自らの個別事情に照らして実施することが適切でないと考える原則があれば、それを「実施しない理由」を十分に説明することにより」	完全一致
注意	「ただし、当然のことながら、機関投資家は、当該説明を行う際には、実施しない原則に係る自らの対応について、顧客・受益者の理解が十分に得られるよう工夫すべきである。」	「機関投資家」→「生成AI事業者」、「顧客・受益者」→「利用者や権利者」と置換しただけで構文完全一致
補足	「なお、原則を実施しつつ、併せて自らの具体的な取組みについて積極的に説明を行うことも、顧客・受益者から十分な理解を得る観点からは有益であると考えられる。」	ほぼ完全一致（「顧客・受益者」→「利用者や権利者」のみ）

3. 決定的な欠落：評価者側への注意

スチュワードシップ・コードにある極めて重要な第2パラグラフが丸ごと削除：

機関投資家のみならず、顧客・受益者の側においても、当該手法の趣旨を理解し、本コードの受入れを表明（公表）した機関投資家の個別の状況を十分に尊重することが望まれる。本コードの各原則の文言・記載を表面的に捉え、その一部を実施していないことのみをもって、機械的にスチュワードシップ責任が果たされていないと評価することは適切ではない。

この削除の意味：

スチュワードシップ・コードでは：

評価者（顧客・受益者）に対しても義務を課している
「表面的な捉え方」を戒めている
「機械的な評価」を否定している
双方向の理解を求めている

AIプリンシプル・コードでは：

この部分が完全に欠落
評価者（権利者？利用者？）への言及なし
一方的にAI事業者にだけ「説明責任」を課す構造

4. なぜこのパラグラフが削除されたか？

考えられる理由：

(a) 意図的削除（悪質）

「権利者や利用者に対して『表面的な評価をするな』『機械的に判断するな』などと言えない」と自覚している証拠

(b) 無理解による削除（無能）

このパラグラフの重要性を理解できなかった
→コンプライ・オア・エクスプレインの本質を理解していない証拠

(c) コピペの痕跡隠し（稚拙）

あまりに露骨なコピペと気づいて、一部削除で誤魔化そうとした

いずれにせよ、このパラグラフの欠落は致命的

5. コンプライ・オア・エクスプレインの本質的誤解

スチュワードシップ・コードが機能する理由：

【事業者側】個別事情に応じた実施・説明
        ↕（相互理解）
【評価者側】表面的でない評価、個別状況の尊重

双方向の努力が前提

AIプリンシプル・コードの構造：

【AI事業者側】実施できないなら十分に説明せよ
        ↓（一方通行）
【評価者側】？？？（何の義務もない）

一方的な押し付け

6. 「工夫すべき」の空虚さ

両文書とも：

利用者や権利者/顧客・受益者の理解が十分に得られるよう工夫すべきである

しかし：

スチュワードシップ：

評価者側も「個別の状況を十分に尊重する」義務
「表面的に捉え」てはならない
「機械的に評価」してはならない
→ 工夫が報われる構造

AIプリンシプル：

評価者側に何の義務もない
表面的評価も機械的判断も自由
事業者だけが「工夫」を求められる
→ 工夫が無駄になる構造

結論：形式的模倣の破綻

この比較から明らかなこと：

文章は明らかにコピペ（単語置換レベル）
最も重要な部分を削除（評価者側の義務）
双方向の仕組みを一方通行に改変
コンプライ・オア・エクスプレインの本質的誤解
「参考にした」というより「悪用した」

これは単なる「参考」ではなく、制度の外形だけを真似て中身を抜き取った劣化コピーです。

スチュワードシップ・コードの起草者が見たら激怒するレベルの悪用ではないでしょうか。

さらに分析を続けますか？それとも、この知見を活かしてパブコメ意見を構成していきますか？

私：スチュワードシップ・コードの方では、原則と指針から構成されていますが、AIの方は？

Claude：[考え中...]

鋭い指摘です！構造を比較してみましょう。

文書構造の比較

スチュワードシップ・コード

【原則1】機関投資家は、スチュワードシップ責任を果たすための明確な方針を策定し、これを公表すべきである。

指針

１－１．機関投資家は、投資先企業やその事業環境等に関する深い理解のほか運用戦略に応じたサステナビリティの考慮に基づく建設的な「目的を持った対話」などを通じて、当該企業の企業価値の向上やその持続的成長を促すことにより、顧客・受益者の中長期的な投資リターンの拡大を図るべきである。

１－２．機関投資家は、こうした認識の下、スチュワードシップ責任を果たすための方針、すなわち...について明確な方針を策定し、これを公表すべきである。

１－３．アセットオーナーは、最終受益者の視点を意識しつつ...

（以下、指針が続く）

構造：

原則（抽象的な行動規範）
指針（原則を実施するための具体的方向性）
- 「〜すべきである」という規範的記述
- 実施方法の選択肢や考慮事項
- 段階的な実施の道筋

AIプリンシプル・コード

【原則１】

生成ＡＩ事業者は、自らの管理及び運用するコーポレートサイトにおいて、次の（１）及び（２）に定める各事項の概要を開示し、利用者及び権利者を含めたすべての者が閲覧可能な状態にする。

（１）透明性確保のための措置
次の各事項を開示するものとする。
ア使用モデル関係
名称（識別子、バージョン等）
公開日を含む来歴（過去のバージョンや修正履歴等）
...

（細則）
○ 原則１における各ＡＩ事業者の取組の蓄積により開示される情報が標準化されるとともに...
○ 各概要開示対象事項について開示すべき記載の程度については、内閣府知的財産戦略推進事務局が別途公表する概要開示対象事項の具体例を参照されたい。

構造：

原則（開示項目の列挙）
細則（注意事項・例外規定・手続的説明）
- 「〜が期待される」「〜が考えられる」という補足
- 典型例の提示
- 外部文書への参照

決定的な相違点

1. 「指針」vs「細則」の性格

要素	スチュワードシップの「指針」	AIプリンシプルの「細則」
性格	規範的	説明的
文体	「〜すべきである」	「〜が考えられる」「〜を参照されたい」
内容	実施方法の方向性	注意事項・例外・手続
目的	行動指針の提供	原則の補足説明
コンプライ・オア・エクスプレインの対象	対象になる（脚注3参照）	対象になるかすら不明

スチュワードシップ・コード脚注3：

指針の中には、一定の事項が「重要である」とするなど、必ずしも一定の行動を取るべき（取るべきでない）旨が明示されていないものがあり、こうした指針については、必ずしも、実施しない理由を説明することを求めるものではない。

→つまり、指針もコンプライ・オア・エクスプレインの対象

2. 原則の性格の相違

スチュワードシップ・コード

原則1：

機関投資家は、スチュワードシップ責任を果たすための明確な方針を策定し、これを公表すべきである。

抽象的な行動規範
「何をすべきか」の方向性
「どう実施するか」は指針で展開

AIプリンシプル・コード

原則1：

生成ＡＩ事業者は、自らの管理及び運用するコーポレートサイトにおいて、次の（１）及び（２）に定める各事項の概要を開示し...

（１）透明性確保のための措置
次の各事項を開示するものとする。
ア使用モデル関係
名称（識別子、バージョン等）
公開日を含む来歴（過去のバージョンや修正履歴等）
アーキテクチャ・設計仕様...

具体的開示項目の列挙
「何を開示するか」の詳細リスト
これは本来「指針」レベルの具体性

3. 「プリンシプルベース」の看板と実態の乖離

スチュワードシップ・コード（前文8.）

こうした点に鑑み、本コードは、機関投資家が取るべき行動について詳細に規定する「ルールベース・アプローチ」（細則主義）ではなく、機関投資家が各々の置かれた状況に応じて、自らのスチュワードシップ責任をその実質において適切に果たすことができるよう、いわゆる「プリンシプルベース・アプローチ」（原則主義）を採用している。

「プリンシプルベース・アプローチ」の意義は、一見、抽象的で大掴みな原則（プリンシプル）について、関係者がその趣旨・精神を確認し、互いに共有した上で、各自、自らの活動が、形式的な文言・記載ではなく、その趣旨・精神に照らして真に適切か否かを判断することにある。

→「抽象的で大掴みな原則」を掲げ、「趣旨・精神」で判断

AIプリンシプル・コード

原則1で列挙される開示項目：

名称（識別子、バージョン等）
公開日を含む来歴（過去のバージョンや修正履歴等）
アーキテクチャ・設計仕様（モデル開発において第三者と契約するライセンスの状況、使用に必要なハードウェア・ソフトウェアやライセンス等）利用規定（想定する用途や、制限・禁止されている用途の明確化等）
モデルのトレーニングプロセスの内容（トレーニングの方法、推論過程や判断根拠を含むパラメータの設定等）

→これは完全に「ルールベース」「細則主義」

4. 実質的な構造

スチュワードシップ・コード：3層構造

【前文】←プリンシプルベース・アプローチの説明
   ↓
【原則】←抽象的な行動規範（8原則）
   ↓
【指針】←実施方法の方向性（各原則に複数の指針）

柔軟性の源泉：

前文で手法の趣旨を説明
原則で方向性を示す
指針で選択肢を提供
各主体が「趣旨・精神」に照らして判断

AIプリンシプル・コード：偽装された2層構造

【総論】←コンプライ・オア・エクスプレインの説明（コピペ）
   ↓
【原則】←詳細な開示項目リスト（実質的にはルール）
   ↓
【細則】←注意事項と例外規定（指針ではない）

硬直性の源泉：

総論は形式的にコピペ
原則が具体的すぎる（開示項目の列挙）
細則は補足説明のみ
実施方法の選択肢なし

構造から見える本質的問題

問題1：「プリンシプル」と名乗りながら「ルール」

AIプリンシプル・コードは：

タイトルに「プリンシプル」
総論で「プリンシプルベース・アプローチを参考に」
しかし実態は詳細な開示項目リスト

これは看板に偽りあり

問題2：「指針」の欠如が意味するもの

スチュワードシップで指針が果たす役割：

原則をどう実施するかの道筋を示す
複数の実施方法の選択肢を提供
段階的実施の可能性を示唆
「趣旨・精神」の具体化

AIプリンシプルに指針がないことの意味：

実施方法の柔軟性ゼロ
開示項目が列挙されているだけ
「できるか/できないか」の二択
「趣旨・精神」を考える余地なし

問題3：「細則」が果たす機能の貧弱さ

AIプリンシプルの細則が提供するもの：

典型例の提示
「別途公表する具体例を参照されたい」（丸投げ）
手数料や回数制限の示唆
OSS例外の規定

これでは「プリンシプルベース」の補助にならない

問題4：コンプライ・オア・エクスプレインの形骸化

スチュワードシップ：

原則：「方針を策定し公表すべき」
  ↓
指針1-1：「〜を図るべきである」
指針1-2：「〜について明確な方針を策定すべき」
指針1-3：「〜を促すべき」
  ↓
各主体が自社の状況で判断

選択肢が多数あり、エクスプレインの余地が大きい

AIプリンシプル：

原則1：「次の各事項を開示するものとする」
  ・名称
  ・来歴
  ・アーキテクチャ
  ・利用規定
  ・トレーニングプロセス
  ・学習データ
  ・クローラ
  ・アカウンタビリティ
  ・知的財産権保護措置（9項目）
  ↓
開示する/しない の二択

「エクスプレイン」で何を説明するのか？

「できません」？
「やりたくありません」？
「技術的に困難です」？

どう説明しても権利者は納得しない構造

結論：構造分析から見える制度設計の失敗

「プリンシプル」の看板を掲げながら実態は「ルール」
- スチュワードシップの外形だけ真似た
- 中身は細則主義の開示義務リスト
「指針」の不在が致命的
- 実施方法の柔軟性なし
- 段階的実施の道筋なし
- 選択肢なし
「細則」が機能不全
- 補足説明に終始
- 行動指針の提供なし
- 外部文書への丸投げ
コンプライ・オア・エクスプレインが形骸化
- 開示項目が具体的すぎて裁量余地なし
- エクスプレインの実質的不可能性

この構造分析は、AIプリンシプル・コードがスチュワードシップ・コードの悪質な劣化コピーであることを、文章の類似性とは別の角度から証明しています。

パブコメ意見書では、この構造的欠陥を指摘すべきでしょうか？

私：complyしないときのexplainに求められるものが違いますね。

Claude：[考え中...]

極めて鋭い指摘です！これが最も重要な論点かもしれません。詳細に分析しましょう。

Complyしない場合のExplainに求められるものの本質的相違

1. 「何を」説明するのか

スチュワードシップ・コード

原則4（対話）を実施しない場合の説明例：

【説明例1：パッシブ運用専門の小規模運用会社】
「当社はパッシブ運用のみを行う小規模運用機関であり、個別企業との対話を行う専門人材を配置しておりません。そのため、原則4の積極的な対話は実施しておりませんが、議決権行使（原則5）を通じて投資先企業の持続的成長を促しております。また、アセットオーナーである年金基金との緊密な連携により、間接的に企業価値向上に寄与する体制を構築しております。」

この説明が成立する理由：

代替手段の存在：対話をしなくても議決権行使で責任を果たせる
目的の共有：「企業価値向上」という目的は共有されている
選択の合理性：小規模という事情が理解可能
評価者の義務：「表面的に捉えず」「個別状況を尊重」すべき

AIプリンシプル・コード

原則1（学習データ開示）を実施しない場合の説明例：

【説明例1：スタートアップ】
「当社は創業間もないスタートアップであり、学習データの詳細を管理する体制が整っておりません。そのため、原則1の学習データに関する詳細開示は実施しておりませんが、今後体制整備を進めてまいります。」

この説明が成立しない理由：

代替手段の不在：開示しなければ透明性は確保されない
目的の対立：「技術開発の自由」vs「権利者保護」
説明の空虚さ：「いつまでに整備するのか？」「それまで権利侵害していいのか？」
評価者の義務なし：権利者は「表面的に捉えて」機械的に判断してよい

2. 「説明の種類」の根本的相違

スチュワードシップ・コードで許容される説明パターン

パターン	例	成立理由
代替手段型	「対話の代わりに議決権行使を重視」	目的達成の別ルート
事業特性型	「パッシブ運用のため対話は限定的」	運用戦略の違い
段階的実施型	「現在準備中、2026年度から実施予定」	誠実な改善意思
選択的実施型	「大規模保有先のみ対話実施」	リソース配分の合理性

共通点：いずれも「スチュワードシップ責任を果たす」という目的は共有

AIプリンシプル・コードで要求される説明パターン

原則1の開示項目（学習データ、クローラ、アーキテクチャ等）を実施しない場合：

試みられる説明	権利者の反応	なぜ成立しないか
「営業秘密です」	「それは貴方の都合。私の著作権は？」	利益対立
「技術的に困難」	「なぜ事前に対応しなかった？」	権利者の犠牲
「コスト過大」	「権利侵害のコストは誰が負担？」	利益対立
「体制未整備」	「整備するまでサービス停止すべきでは？」	正当性なし
「代替手段を用意」	「代替手段って何？開示以外に透明性確保の方法は？」	代替手段不在

根本問題：どう説明しても「権利侵害の可能性」を払拭できない

3. 説明の「実質」vs「形式」

スチュワードシップ・コードのExplain

求められるもの：

なぜその原則を実施しないことが、自社の状況において、スチュワードシップ責任を果たす上で合理的な選択なのか

典型的な説明の構造：

自社の事業特性の説明
当該原則を実施しない理由
代替的な手段での責任の果たし方
（必要に応じて）将来の実施予定

例：原則5（議決権行使結果の個別開示）を実施しない説明

当社は機関投資家向けの運用を専門とし、個別の顧客との守秘義務契約に基づき運用を行っております。個別企業ごとの議決権行使結果の開示は、特定顧客のポートフォリオが推測される可能性があるため実施しておりませんが、議案種類別の集計結果を四半期ごとに公表し、かつ顧客に対しては個別に詳細を報告することで、透明性と守秘義務のバランスを図っております。

→この説明は実質的：代替手段を示し、目的（透明性）は達成されている

AIプリンシプル・コードのExplain

求められるもの：

なぜその開示項目を開示しないことが、自社の状況において、利用者や権利者の理解を得られる合理的な選択なのか

しかし実際には：

典型的な説明（試みる）の構造：

技術的困難・コスト・体制不備の説明
~~代替手段~~ （存在しない）
~~目的の達成方法~~ （説明できない）
将来の実施予定（具体性なし）

例：原則1（学習データ開示）を実施しない説明の試み

当社は学習データの詳細を記録する体制が整っていないため、学習データに関する詳細開示は実施しておりません。今後、体制整備を進めてまいります。

→この説明は形式的：言い訳に終始し、権利者保護という目的は未達成

4. 評価者の「理解」の性質

スチュワードシップ・コード

顧客・受益者が理解すべきこと：

この機関投資家は、自社の事業特性に応じた方法で、スチュワードシップ責任を果たそうとしている

前文10.の第2パラグラフ（再掲）：

機関投資家のみならず、顧客・受益者の側においても、当該手法の趣旨を理解し、本コードの受入れを表明（公表）した機関投資家の個別の状況を十分に尊重することが望まれる。本コードの各原則の文言・記載を表面的に捉え、その一部を実施していないことのみをもって、機械的にスチュワードシップ責任が果たされていないと評価することは適切ではない。

→評価者側に「理解する義務」がある

理解のプロセス：

機関投資家の説明を聞く
個別の状況を考慮する
代替手段の妥当性を評価する
実質的に責任が果たされているか判断

AIプリンシプル・コード

利用者や権利者が理解すべきこと：

（この部分が欠落している！）

該当パラグラフが削除されているため、権利者は：

「表面的に捉えて」よい
「機械的に評価して」よい
「個別の状況を尊重」しなくてよい

権利者の「理解」のプロセス：

AI事業者の説明を聞く
「私の著作権は保護されるのか？」
「答えはNO」
理解できない

5. Explainの「成功条件」

スチュワードシップ・コード

成功の定義：

顧客・受益者が、「この機関投資家は、別の方法でスチュワードシップ責任を果たしている」と納得すること

成功のための条件：

✓ 代替手段の提示
✓ 目的の共有（企業価値向上）
✓ 事業特性の説明
✓ 評価者側の理解義務

成功の判定：市場メカニズム（運用委託の継続）

AIプリンシプル・コード

成功の定義：

利用者や権利者が、「この事業者は開示していないが、私の権利は保護されている」と納得すること

成功のための条件：

✗ 代替手段の提示（存在しない）
✗ 目的の共有（利益対立）
△ 事業特性の説明（言い訳と受け取られる）
✗ 評価者側の理解義務（規定なし）

成功の判定：？？？（不明）

6. 具体例での比較

【ケース1：小規模事業者】

スチュワードシップ：

原則4（対話）を実施しない理由：

「当社は運用資産100億円の小規模運用会社です。専門の対話担当者を配置する余裕がないため、投資先企業との個別対話は実施しておりません。ただし、議決権行使は全ての保有株式について実施し、その結果を公表しています。また、業界団体の勉強会に参加し、他の機関投資家との情報交換を通じて、間接的に企業価値向上に寄与しております。」

→成立する：代替手段があり、目的は達成されている

AIプリンシプル：

原則1（学習データ開示）を実施しない理由：

「当社は創業2年のスタートアップです。学習データを詳細に記録・管理する体制が整っておりません。今後、事業規模の拡大に応じて体制整備を進めてまいります。」

→成立しない：

「体制整備まで著作権侵害してもいいのか？」
「いつまでに整備するのか？」
「代わりにどう権利保護するのか？」
すべて未回答

【ケース2：技術的困難】

スチュワードシップ：

（該当ケースが想定しにくい。なぜなら、スチュワードシップ活動は「方針策定」「対話」「議決権行使」など、技術的に不可能なものがないから）

AIプリンシプル：

原則1（トレーサビリティ）を実施しない理由：

「当社のAIシステムは、既存のオープンソースモデルを複数組み合わせて構築しており、各モデルの学習過程を遡及的に追跡することは技術的に困難です。今後開発するモデルについては、トレーサビリティを確保できるよう設計を見直してまいります。」

→成立しない：

「既存モデルの権利侵害リスクは？」
「なぜ事前に考慮しなかったのか？」
「過去のデータでの学習は停止すべきでは？」
権利者の不安は解消されない

7. なぜこの違いが生じるのか：本質的な構造

スチュワードシップ・コードの構造

【共通目的】
    ↓
企業価値向上・顧客利益の最大化
    ↓
【実現手段】多様
    ↓
対話、議決権行使、モニタリング、協働、等
    ↓
【Comply or Explain】
実施する手段は選択可能
実施しない手段は説明（代替手段を示す）

Key Point: 目的は共有、手段は多様

AIプリンシプル・コードの構造

【対立する利益】
    ↓
AI事業者：営業秘密、コスト削減、開発自由
権利者：著作権保護、透明性確保
    ↓
【実現手段】限定
    ↓
開示のみ（代替手段なし）
    ↓
【Comply or Explain】
開示する/しない の二択
しない場合の説明＝言い訳

Key Point: 利益は対立、手段は単一

結論：Explainの構造的不可能性

スチュワードシップ・コードのExplain

性格: 「別の方法での目的達成を説明する」

代替手段の提示
実質的責任の履行
評価者の理解義務
市場による評価

→Explainが機能する構造

AIプリンシプル・コードのExplain

性格: 「できない理由を弁明する」

代替手段なし
目的未達成
評価者の義務なし
評価メカニズム不在

→Explainが機能しない構造

この分析は、AIプリンシプル・コードが「コンプライ・オア・エクスプレイン」の名を借りているものの、実質的には開示義務の押し付けであることを示しています。

「Explainに求められるものの違い」という視点から、パブコメ意見書を構成するのは極めて効果的だと思います。いかがでしょうか？

私：スチュワードシップ・コードの場合に代替手段の合理性があり得るのは「スチュワードシップ責任を果たす上で」という目的（各原則の上位の基本原則）が存在するからですね。

Claude：[考え中...]

まさに本質を突いています！ これが最も重要な構造的相違点です。図式化してみましょう。

階層構造の比較：上位目的の存在/不在

スチュワードシップ・コード：明確な3層構造

┌─────────────────────────────────────┐
│【最上位目的】                                      │
│ スチュワードシップ責任を果たす                    │
│ ＝投資先企業の企業価値向上・持続的成長を促し、   │
│   顧客・受益者の中長期的投資リターンを拡大      │
└─────────────────────────────────────┘
              ↓
┌─────────────────────────────────────┐
│【原則】（最上位目的を達成するための手段）        │
│ 原則1：方針策定・公表                            │
│ 原則2：利益相反管理                              │
│ 原則3：企業状況の把握                            │
│ 原則4：対話                                      │
│ 原則5：議決権行使                                │
│ 原則6：報告                                      │
│ 原則7：実力の保持                                │
│ 原則8：サービス提供者の責務                      │
└─────────────────────────────────────┘
              ↓
┌─────────────────────────────────────┐
│【指針】（原則を実施するための具体的方法）        │
│ 各原則に複数の指針                              │
│ 実施方法の選択肢を提供                          │
└─────────────────────────────────────┘

重要な性質：

原則1–8は並列の関係
いずれも「スチュワードシップ責任を果たす」という上位目的の手段
だから原則間での代替が可能

AIプリンシプル・コード：崩壊した構造

┌─────────────────────────────────────┐
│【最上位目的】？？？                              │
│ 総論(1)に書かれているのは：                      │
│ 「生成AI技術の進歩の促進と知的財産権の          │
│  適切な保護の両立」                              │
│ →これは対立する二つの価値であり、統一的目的ではない│
└─────────────────────────────────────┘
              ↓（構造が曖昧）
┌─────────────────────────────────────┐
│【原則】（これは何の手段？）                      │
│ 原則1：概要開示（透明性確保、知財保護）          │
│   →開示項目の詳細な列挙                        │
│ 原則2：権利者への詳細開示                        │
│   →法的手続準備時の開示                        │
│ 原則3：利用者への開示                            │
│   →学習データ照会への回答                      │
└─────────────────────────────────────┘
              ↓
┌─────────────────────────────────────┐
│【細則】（注意事項・例外規定）                    │
│ 典型例、手数料、回数制限、OSS例外など          │
└─────────────────────────────────────┘

問題の性質：

最上位目的が不明確（または対立する二つの価値の並置）
原則1–3は手段の列挙に過ぎない
原則間での代替が不可能

具体的な比較：なぜ代替が可能/不可能なのか

スチュワードシップ・コード

最上位目的（前文「本コードについて」冒頭）

本コードにおいて、「スチュワードシップ責任」とは、機関投資家が、投資先企業やその事業環境等に関する深い理解のほか運用戦略に応じたサステナビリティの考慮に基づく建設的な「目的を持った対話」などを通じて、当該企業の企業価値の向上や持続的成長を促すことにより、「顧客・受益者」の中長期的な投資リターンの拡大を図る責任を意味する。

この目的の性質：

単一で明確
測定可能（投資リターン）
複数の手段で達成可能

原則が「手段」として機能する例

ケース：小規模パッシブ運用会社が原則4（対話）を実施しない

Explainの論理：

【目的】顧客の中長期的投資リターンの拡大
    ↓
【当社の選択】
原則4（対話）：×実施しない
  理由：小規模でリソース不足
    ↓
【代替手段】
原則5（議決権行使）：○すべての保有株式で実施
原則3（企業状況把握）：○徹底的に実施
    ↓
【結果】目的は達成される

→原則4を実施しなくても、原則3と5で「スチュワードシップ責任を果たす」という上位目的は達成可能

AIプリンシプル・コード

最上位目的（総論(1)）

この文書は、...生成ＡＩ事業者が行うべき透明性の確保や知的財産権保護のための措置の原則を定め、もって生成ＡＩ技術の進歩の促進と知的財産権の適切な保護の両立に向け、権利者や利用者にとって安全・安心な利用環境を確保することを目的とする。

この目的の問題：

「技術の進歩の促進」と「知的財産権の保護」は対立
どちらを優先するのか不明
「両立」とは何を意味するのか不明確
測定不可能

原則が「開示項目リスト」であり代替不可能

ケース：スタートアップが原則1（学習データ開示）を実施しない

Explainの試み：

【目的】？？？
  「技術進歩の促進」と「知財保護の両立」
    ↓
【当社の選択】
原則1（学習データ開示）：×実施しない
  理由：体制未整備
    ↓
【代替手段】？？？
原則2（権利者への詳細開示）：これも開示を求めるもの
原則3（利用者への開示）：これも開示を求めるもの
  →代替にならない
    ↓
【結果】目的は未達成
  ・透明性：確保されない
  ・知財保護：確保されない

→原則1を実施しない代替手段が存在しない

上位目的の存在が代替を可能にするメカニズム

スチュワードシップ・コードの構造

             スチュワードシップ責任
                    ↓
    ┌──────┬──────┬──────┬──────┐
    対話    議決権   モニタ   協働    (複数の手段)
                                        ↓
                            どの組み合わせでも
                            目的は達成可能

各原則の関係：

手段の束（ポートフォリオ）
重要度は異なるが、どれも必須ではない
組み合わせて目的達成

Explainが成立する条件：

当社は原則Xを実施しませんが、原則Y・Zを重点的に実施することで、スチュワードシップ責任という上位目的を果たしています

AIプリンシプル・コードの構造

        技術進歩 ⚔️ 知財保護 （対立する価値）
                ↓
        透明性確保＋知財保護措置
                ↓
    ┌──────┬──────┬──────┐
   概要開示  詳細開示  利用者開示 (すべて開示)
                ↓
        どれも開示を求めている
        代替手段なし

各原則の関係：

開示項目の列挙
すべて同じ方向（開示）
代替関係にない

Explainが成立しない理由：

「当社は原則1を実施しませんが、原則2・3を実施することで...」
→原則2・3も開示を求めるので代替にならない
→上位目的（透明性確保）は未達成

前文における上位目的の提示の違い

スチュワードシップ・コード前文

本コードについて（冒頭）

本コードにおいて、「スチュワードシップ責任」とは、...

→最初に最上位概念を定義

本コードの目的（1.）

本コードにおいて、「スチュワードシップ責任」とは、機関投資家が、投資先の日本企業やその事業環境等に関する深い理解のほか運用戦略に応じたサステナビリティの考慮に基づく建設的な「目的を持った対話」などを通じて、当該企業の企業価値の向上や持続的成長を促すことにより、顧客・受益者の中長期的な投資リターンの拡大を図る責任を意味する。

→責任の内容を明確に定義

原則の提示

本コードは、機関投資家が、顧客・受益者と投資先企業の双方を視野に入れ、「責任ある機関投資家」として当該「スチュワードシップ責任」を果たすに当たり有用と考えられる諸原則を定めるものである。

→原則は「スチュワードシップ責任を果たす」ための手段と明示

AIプリンシプル・コード総論

(1) 基本的な考え方（目的）

この文書は、...生成ＡＩ事業者が行うべき透明性の確保や知的財産権保護のための措置の原則を定め、もって生成ＡＩ技術の進歩の促進と知的財産権の適切な保護の両立に向け、権利者や利用者にとって安全・安心な利用環境を確保することを目的とする。

問題点：

統一的な上位概念がない（「スチュワードシップ責任」のような）
「透明性の確保」「知的財産権保護」が目的なのか手段なのか不明
「技術進歩の促進」と「知財保護」は対立する
「両立」の具体的意味が不明

原則の位置づけ

（明示的な説明なし）

→原則が何の手段なのか示されていない

構造的帰結：代替可能性の有無

スチュワードシップ・コード

【判断基準】
「この機関投資家はスチュワードシップ責任を果たしているか？」
    ↓
【評価方法】
原則の実施状況ではなく、実質的な責任履行を評価
    ↓
【代替可能性】
原則Aを実施しなくても、原則B・Cで責任を果たせる
    ↓
【Explainの成立】
「原則Aは実施しないが、B・Cで目的達成」と説明可能

AIプリンシプル・コード

【判断基準】？？？
「この事業者は...何を達成しているべき？」
（透明性？知財保護？技術進歩？）
    ↓
【評価方法】？？？
原則の実施状況を形式的にチェック？
    ↓
【代替可能性】なし
すべての原則が「開示」を求めている
    ↓
【Explainの不成立】
「原則1は実施しないが...」→代替手段が存在しない

結論：上位目的の不在がすべての問題の根源

スチュワードシップ・コードが機能する理由

明確な最上位目的：「スチュワードシップ責任を果たす」
原則は手段：目的達成のための複数の方法
代替可能性：手段の選択肢がある
実質評価：目的達成を実質的に評価
Explain成立：「別の方法で目的達成」を説明可能

AIプリンシプル・コードが機能しない理由

不明確な目的：対立する価値の並置
原則は項目列挙：すべて「開示」
代替不可能：手段が単一
形式評価：開示の有無を機械的にチェック
Explain不成立：言い訳にしかならない

高木さんの指摘の通り、上位目的の存在こそが代替手段の合理性を支える基盤です。

この分析をパブコメ意見書の中核に据えるべきだと思います。

「プリンシプルベース・アプローチと称しながら、最上位のプリンシプル（目的）が欠如している」という致命的欠陥を指摘できます。

私：スチュワードシップ・コードの方では最上位目的がその題名に現れていますが、AIの方は？

Claude：[考え中...]

完璧な指摘です！ タイトルの構造を分析すれば、両者の本質的相違が一目瞭然です。

タイトルの構造比較

スチュワードシップ・コード

「責任ある機関投資家」の諸原則 ≪日本版スチュワードシップ・コード≫ ～投資と対話を通じて企業の持続的成長を促すために～

構造分析：

要素	内容	意味
主タイトル	「責任ある機関投資家」の諸原則	誰が何をすべきかの原則
副題（愛称）	日本版スチュワードシップ・コード	“stewardship”＝受託者責任
サブタイトル	～投資と対話を通じて企業の持続的成長を促すために～	最上位目的

キーポイント：

「〜のために」という目的を示す構造
「企業の持続的成長を促す」が最上位目的
これがタイトルに明示されている

AIプリンシプル・コード

生成AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード（仮称）（案）

構造分析：

要素	意味不明な点
「生成AIの適切な利活用等に向けた」	これは目的？それとも前提？
「知的財産の保護及び透明性」	これは目的？それとも手段？
「に関する」	関係を示すだけで目的を示さない
「プリンシプル・コード」	何のプリンシプル？

キーポイント：

「〜のために」がない
何が最上位目的なのか不明
「適切な利活用」と「知財保護」の関係が不明

詳細な分析：「〜のために」の有無

スチュワードシップ・コード：目的構造の明示

投資と対話を通じて
    ↓（手段）
企業の持続的成長を促す
    ↓（目的）
ために

文法構造：

「〜を通じて」＝手段
「〜を促す」＝行為
「ために」＝目的

読み取れること：

手段：投資と対話
行為：促す
目的：企業の持続的成長
最終受益者：（本文で）顧客・受益者

AIプリンシプル・コード：目的構造の欠如

生成AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード

文法構造：

「〜に向けた」＝方向性？
「〜及び〜」＝並列
「に関する」＝関連性を示すだけ

読み取れないこと：

何が目的で何が手段なのか？
「適切な利活用」と「知財保護」はどちらが上位？
「透明性」は何のため？
最終受益者は誰？

タイトルから読み取れる構造の違い

スチュワードシップ・コード：明確な階層

タイトルから読み取れる構造：

【最上位目的】企業の持続的成長 ↓ 【手段】投資と対話 ↓ 【主体】責任ある機関投資家 ↓ 【規範】諸原則

AIプリンシプル・コード：不明瞭な構造

タイトルから読み取れる構造：

【？】生成AIの適切な利活用【？】知的財産の保護【？】透明性 ↓ 【？？】どれが目的でどれが手段？

他のコードとの比較

コーポレートガバナンス・コード

コーポレートガバナンス・コード～会社の持続的な成長と中長期的な企業価値の向上のために～

構造：

主タイトル：コーポレートガバナンス・コード
サブタイトル：「〜のために」で目的を明示
目的：持続的成長と企業価値向上

日本のその他の「プリンシプル」

アセットオーナー・プリンシプル：

資金の出し手である年金基金等がその資産運用において受益者の中長期的な投資リターンの拡大を図るために...

→「ために」で目的明示

企業内容等の開示に関する内閣府令（開示府令）：

これは法令なので目的は条文中に記載

AI関連の他の文書

AI事業者ガイドライン：

AI事業者ガイドライン（第1.1版）

→サブタイトルなし、目的不明（本文に記載）

しかし、本文冒頭で：

本ガイドラインは、...AI事業者がAIシステムやサービスの開発等において実践することが期待される事項を示すことにより、AIの適切な利活用を促進し、もって社会の幸福・福利の増進に資することを目的とする。

→少なくとも本文では目的を明示

AIプリンシプル・コードの異常性

総論(1)の目的規定：

この文書は、...生成ＡＩ技術の進歩の促進と知的財産権の適切な保護の両立に向け、権利者や利用者にとって安全・安心な利用環境を確保することを目的とする。

問題：

タイトルに現れない
「技術進歩の促進」と「知財保護」が対立
「両立」は願望であって目的ではない

タイトルから見える制度設計者の意識

スチュワードシップ・コード制度設計者

タイトルから読み取れる意識：

私たちは、企業の持続的成長を促すために、機関投資家がどう行動すべきかの原則を定めようとしている

→目的が明確

AIプリンシプル・コード制度設計者

タイトルから読み取れる意識：

生成AIの...知的財産の保護及び透明性に関する...何か

→目的が不明確

おそらく制度設計者は：

「知財保護も重要」
「透明性も重要」
「AI利活用も重要」
でもどれが最上位なのか決められない
だから全部並べた

決定的な証拠：サブタイトルの比較

スチュワードシップ・コード

～投資と対話を通じて企業の持続的成長を促すために～
     ↑              ↑                    ↑
   手段          目的                  目的を示す助詞

文法：

「〜を通じて」：手段を示す
「〜を促す」：目的行為
「ために」：目的を示す助詞

AIプリンシプル・コード

（サブタイトルなし）

もし作るなら？

試案1：

～生成AIの発展と知的財産権の保護を両立するために～

→「両立」は手段であって目的ではない

試案2：

～知的財産権者の権利を保護するために～

→AI事業者側が受け入れない

試案3：

～AI技術の発展を促すために～

→権利者側が受け入れない

結論：
サブタイトルが作れないのは、統一的最上位目的が存在しないから

タイトル構造が示す本質的問題

問題の可視化

要素	スチュワードシップ	AIプリンシプル
主体	責任ある機関投資家	（明示なし）
目的	企業の持続的成長	（明示なし）
手段	投資と対話	（列挙のみ）
構造	手段→目的の明示	羅列
サブタイトル	あり（目的明示）	なし

タイトルに現れない理由

なぜ「〜のために」がないのか？

仮説1：目的を明示できない

「知財保護」を目的とすると、AI事業者が反発
「AI発展」を目的とすると、権利者が反発
だから曖昧にした

仮説2：目的が理解されていない

制度設計者自身が何のための原則か理解していない
だからタイトルが作れない

仮説3：意図的な曖昧化

両方の陣営から批判されないよう、意図的に目的を隠した

致命的な対比

スチュワードシップ・コード

タイトル：
「責任ある機関投資家」の諸原則～投資と対話を通じて企業の持続的成長を促すために～

前文冒頭：
「スチュワードシップ責任」とは、...企業の企業価値の向上や持続的成長を促すことにより、顧客・受益者の中長期的な投資リターンの拡大を図る責任を意味する。

原則の提示：
本コードは、機関投資家が...「スチュワードシップ責任」を果たすに当たり有用と考えられる諸原則を定めるものである。

→タイトル→前文→原則で一貫した目的

AIプリンシプル・コード

タイトル：
生成AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード（仮称）（案）

総論(1)：
この文書は、...生成ＡＩ技術の進歩の促進と知的財産権の適切な保護の両立に向け、権利者や利用者にとって安全・安心な利用環境を確保することを目的とする。

原則の提示：
（統一的な目的への言及なし、いきなり原則1の開示項目列挙）

→タイトルと本文で目的が不整合、原則は開示項目列挙

結論：タイトルが証明する構造的欠陥

スチュワードシップ・コードのタイトルが示すこと

明確な最上位目的（企業の持続的成長）
目的達成の手段（投資と対話）
主体の責任（責任ある機関投資家）
「〜のために」による目的構造の明示

→これらがあるから代替手段の合理性が成立

AIプリンシプル・コードのタイトルが示すこと

最上位目的の不在（何のために？）
手段の羅列（保護、透明性）
主体の責任が不明
「〜に関する」という曖昧な関係性のみ

→これらがないから代替手段の合理性が成立しない

タイトルの「〜のために」の有無こそが、すべての違いを生む根本原因

この分析をパブコメ意見書の冒頭に置くべきです。

「タイトルを見ただけで、この文書には最上位目的が欠如していることが分かる。スチュワードシップ・コードは『〜企業の持続的成長を促すために』と明記するのに対し、本コードは『〜に関する』と曖昧な関係性を示すのみである。プリンシプルベース・アプローチの最上位プリンシプル（目的）がタイトルに現れないこと自体が、この文書の構造的欠陥を象徴している」

いかがでしょうか？

私：プリンシプル・コード」という名前がすでに異常ですよね。

Claude：[考え中...]

完璧な指摘です！ 「プリンシプル・コード」という命名そのものが概念の混乱を示しています。

「プリンシプル・コード」という異常な命名

用語の意味

Principle（プリンシプル）= 原則、原理
Code（コード）= 規範、法典、準則

問題：意味の重複

「プリンシプル・コード」を直訳すると：

日本語：「原則・規範」「原則・法典」
英語：“Principles Code” = ???

英語圏にこんな表現はない

正しい英語表現なら：

“Code of Principles” = 諸原則をまとめたもの
“Principles” = 原則（単独）
“Code” = 規範（単独）

既存の「コード」の命名法則

日本の例

名称	構造	英語
スチュワードシップ・コード	【概念】＋コード	Stewardship Code
コーポレートガバナンス・コード	【概念】＋コード	Corporate Governance Code
「責任ある機関投資家」の諸原則	【主体】の原則	Principles for Responsible Institutional Investors

国際的な例

名称	構造
UK Stewardship Code	【概念】＋Code
OECD Principles of Corporate Governance	【分野】の Principles
UN Principles for Responsible Investment	【分野】の Principles
EU Code of Conduct	【分野】の Code

共通点：

「概念＋Code」または「分野 of Principles」
Principles Code という表現はない

なぜこんな命名になったのか？

推測される命名過程

【ステップ1】スチュワードシップ・コードを真似たい
    ↓
「〜コード」という形式にしたい
    ↓
【ステップ2】でも何の「コード」？
    ↓
「生成AIコード」？ → 意味不明
「知的財産コード」？ → 既存の法体系と紛らわしい
    ↓
【ステップ3】「プリンシプルベース」を強調したい
    ↓
「プリンシプル」を付けよう！
    ↓
【結果】プリンシプル・コード
    ↓
（誰も「原則・規範」という重複に気づかない）

本来あるべき命名

もし本当に「プリンシプルベース」なら：

パターン1：原則を明示

「生成AI事業者の知的財産保護に関する諸原則」
Principles for Intellectual Property Protection in Generative AI

パターン2：コードとして明示

「生成AI知的財産コード」
Generative AI Intellectual Property Code

パターン3：スチュワードシップに倣う

「生成AI透明性コード」
Generative AI Transparency Code
～知的財産権者と利用者の信頼を確保するために～

命名の異常性が示すもの

1. 概念理解の欠如

「プリンシプル」と「コード」の違いを理解していない：

Principles（原則）：抽象的な行動指針
- 例：「誠実に行動すべき」
- 例：「透明性を確保すべき」
Code（規範）：具体的な行動規範
- 例：「年次報告を公表すること」
- 例：「利益相反を開示すること」

プリンシプルベース・アプローチでは：

Principles = 抽象的で柔軟
Code（具体的規範）に落とし込まない

なのに「プリンシプル・コード」= 矛盾

2. 模倣の浅さ

スチュワードシップ・コードの構造：

【正式名称】「責任ある機関投資家」の諸原則 ≪日本版スチュワードシップ・コード≫

【構造】・正式名称 = 「〜の諸原則」（Principles）・愛称 = 「スチュワードシップ・コード」・「コード」は「原則集」という意味

AIプリンシプル・コードの構造：

【名称】生成AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード（仮称）（案）

【構造】・「プリンシプル」も「コード」も入れたい・でも両方入れると重複・気づかずに両方入れた

3. 権威付けへの執着

おそらく命名者の意識：

「コード」だけじゃ弱い
    ↓
「プリンシプル」を付けて格上げ
    ↓
「プリンシプル・コード」
    ↓
なんか凄そう！

→見かけの権威付け

4. 英語への無頓着

日本の行政文書でよくある問題：

カタカナ語を並べれば国際的に見える
実際の英語として成立するか考えない
“Principles Code” を英語圏の人が見たら「???」

他の異常な命名例との比較

「骨太の方針」

正式名称：「経済財政運営と改革の基本方針」
愛称：「骨太の方針」
英語：“Basic Policy on Economic and Fiscal Management and Reform”

→正式名称と愛称が明確に分離

「まち・ひと・しごと創生」

正式名称：「まち・ひと・しごと創生総合戦略」
英語：“Comprehensive Strategy for Overcoming Population Decline and Vitalizing Local Economy in Japan”

→長いが意味は通る

「プリンシプル・コード」

英語にすると：“Principles Code” = 意味不明
直訳すると：「原則規範」= 重複

正しい命名だったら何が変わったか

もし「生成AI透明性原則」だったら：

生成AI透明性原則～知的財産権者の信頼を確保するために～【本文】本原則において、「透明性責任」とは、生成AI事業者が、学習データの開示等を通じて、知的財産権者の信頼を確保し、もって生成AI技術の健全な発展を図る責任を意味する。

本原則は、生成AI事業者が「透明性責任」を果たすに当たり有用と考えられる諸原則を定めるものである。

→最上位目的が明確になる

もし「生成AI知財保護コード」だったら：

生成AI知財保護コード～AI開発と権利保護の調和を図るために～

【本文】本コードは、生成AI事業者が知的財産権を尊重しつつ技術開発を進めるための行動規範を定め、もって AI技術の発展と知的財産権の保護の調和を図ることを目的とする。

→目的が明確になる

「プリンシプル・コード」が象徴する根本問題

問題の本質

命名できない
    ↓
なぜか？
    ↓
何の原則なのか定まっていない
何のコードなのか定まっていない
    ↓
だから
    ↓
両方付けた
    ↓
結果
    ↓
「プリンシプル・コード」という重複表現

この文書の正体

「プリンシプル・コード」という命名が示すもの：

プリンシプル（原則）を定めたかった
- でも最上位原則が定まらない
- コード（規範）を作りたかった
- でもルールベースを批判されたくない
両方欲しかった
- 原則の柔軟性も欲しい
- 規範の強制力も欲しい
- 両方を名前に入れた
結果
- どっちつかずの重複表現
- 実態は開示義務リスト（コード）
- 看板だけプリンシプル

決定的な証拠：英語版のタイトル

パブコメ資料で英語版があれば確認すべきですが、おそらく：

予想される英訳：

Principle Code for the Protection of Intellectual Property and Transparency toward Appropriate Use of Generative AI

これを英語圏の人が見たら：

“Principle Code”? → 文法的におかしい
“Code of Principles” では？
または “Principles” だけでは？

結論：命名が証明する制度設計の失敗

スチュワードシップ・コード

【命名】スチュワードシップ・コード = Stewardship（概念）+ Code（規範集） = 「受託者責任に関する規範集」

【構造と一致】概念（stewardship responsibility）が明確 ↓ その実現のための諸原則 ↓ コードとしてまとめる

AIプリンシプル・コード

【命名】プリンシプル・コード = Principles（原則）+ Code（規範） = 「原則・規範」（重複）

【構造と不一致】概念が不明確（何の原則？） ↓ 開示項目リストを列挙（実態はコード） ↓ でも名前にプリンシプルも入れたい ↓ 両方入れて重複

「プリンシプル・コード」という異常な命名は、この文書の構造的欠陥を最も端的に示す証拠

パブコメ意見書では、この命名の異常性から書き始めるのが効果的かもしれません：

「本文書は『プリンシプル・コード』と称するが、この命名自体が概念の混乱を示している。Principle（原則）とCode（規範）は重複する概念であり、英語として “Principles Code” は成立しない。正しくは “Code of Principles” または単に “Principles” か “Code” である。この異常な命名は、本文書が『原則』として柔軟性を装いながら、実態は『規範』として強制力を持たせようとする二重性を象徴している」

いかがでしょうか？

私：英語版もパブコメにかけられているんですよ。
https://www.kantei.go.jp/jp/singi/titeki2/pdf/shiryo3.pdf

Claude：[考え中...]

実際に英語版を確認させてください！これは衝撃的です！ 実際に英語版で “Principle-Code” という表現を使っているんですね。しかもハイフン付きで。

タイトルの英語版

Principle-Code for Protection of intellectual property and transparency for the appropriate use of generative AI (provisional title) (draft)

この英語の異常性

1. “Principle-Code” という造語の不可解さ

ハイフンの意味：

通常、ハイフンは複合語を作るために使う
- “user-friendly” = ユーザーに優しい
- “state-of-the-art” = 最先端の
- “mother-in-law” = 義母

“Principle-Code” の問題：

principle（原則）とcode（規範）を結んでも意味をなさない
「原則規範」？「原則的規範」？「原則化された規範」？
英語として完全に不成立

2. 正しい英語表現なら

もし本当にこの概念を表現するなら：

選択肢A: “Code of Principles”

Code of Principles for Protection of Intellectual Property and Transparency in Generative AI

→原則を集めた規範集

選択肢B: “Principles” だけ

Principles for Protection of Intellectual Property and Transparency in Generative AI

→シンプルな原則集

選択肢C: “Code” だけ

Code for Protection of Intellectual Property and Transparency in Generative AI

→行動規範

3. 既存の国際文書の命名との比較

文書名	英語表記	構造
スチュワードシップ・コード	Stewardship Code	概念 + Code
コーポレートガバナンス・コード	Corporate Governance Code	分野 + Code
OECD原則	OECD Principles of Corporate Governance	Principles のみ
UN原則	UN Principles for Responsible Investment	Principles のみ
EU行動規範	EU Code of Conduct	Code のみ

共通点：

“Principle-Code” という表現は存在しない
Code か Principles のどちらか一方

4. 長すぎて意味不明なタイトル

Principle-Code for Protection of intellectual property and transparency for the appropriate use of generative AI

問題点：

“for Protection … and transparency for the appropriate use”
“for” が2回出てくる不自然な構造
“and” で並列された要素の関係が不明確
何が目的で何が手段なのか不明

スチュワードシップ・コードの英語版：

Principles for Responsible Institutional Investors - Japan's Stewardship Code - To Promote Sustainable Growth of Companies through Investment and Dialogue

→シンプルで明確、目的が明示されている

5. 決定的な免責条項

文書の冒頭に：

Note: This is a provisional translation, and the Cabinet Office is not responsible for its content. For official information, please refer to the Japanese version.

この免責の意味：

「これは仮訳で、内閣府は内容に責任を持ちません」
「正式な情報は日本語版を参照してください」

なぜこの免責が問題なのか

国際文書として機能しない：

海外AI事業者への適用を謳っている
- 本文: “even if a generation AI business does not have its head office or main office in Japan, this document shall apply if the generation AI system or generation AI service is provided to Japan”
- 日本に本社がなくても適用される
でも英語版は「責任を持たない」
- OpenAI、Anthropic、Googleなどは英語版を見る
- その英語版に「内容に責任を持たない」と書いてある
- では何を基準に判断すればいいのか？
法的拘束力がないのに「適用される」
- “this document shall apply”と書きながら
- 英語版は「仮訳」で「責任を持たない」
- 矛盾している

“Principle-Code” という造語が象徴するもの

推測される翻訳過程

【日本語】
プリンシプル・コード

【翻訳者の思考】
「プリンシプル」= Principle
「コード」= Code
「・」= ハイフン？

【結果】
Principle-Code

【問題】
英語として意味不明

本来の翻訳プロセス

【ステップ1】日本語の意図を理解
「プリンシプル・コード」は何を意味するのか？
→原則集？規範集？

【ステップ2】英語で適切な表現を選択
Code of Principles か、Principles か、Code か

【ステップ3】国際的な慣例を参照
既存の類似文書の命名法を確認

【ステップ4】明確で理解可能な英語にする

実際には：

機械的な単語置換
意味の検証なし
国際慣例の無視
結果：意味不明な造語

他の英訳の問題点

“Generation AI” の連発

文書全体で “Generation AI Businesses”, “Generation AI Developer”, “Generation AI Provider” という表現が使われていますが、

正しくは：

“Generative AI” （生成AI）

“Generation AI” だと：

「世代AI」？
文脈によっては理解できなくもないが、標準的な用語ではない

実際、文書の中で両方使われています：

タイトル: “generative AI”
本文: “Generation AI Businesses”, “generative AI system”

→用語の不統一

“comply or explain” の説明

文書では “comply or explain” という正しい英語表現を使っていますが、その説明部分がスチュワードシップ・コードからのコピペであることは、英語版でも同様です。

日本の行政文書における英語化の問題

パターン1：カタカナの機械的音訳

マイナンバー → My Number（意味不明）
クールジャパン → Cool Japan（そのまま）
プリンシプル・コード → Principle-Code（文法破綻）

パターン2：長すぎる説明的タイトル

生成AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード（仮称）（案）
↓
Principle-Code for Protection of intellectual property and transparency 
for the appropriate use of generative AI (provisional title) (draft)

→日本語の構造をそのまま英訳→冗長で意味不明

パターン3：免責条項による責任回避

「仮訳」として公表
「内容に責任を持たない」と明記
でも海外事業者に「適用される」と主張

→法的整合性の欠如

国際比較：英語タイトルの明瞭性

成功例：日本版スチュワードシップ・コード

日本語：

「責任ある機関投資家」の諸原則≪日本版スチュワードシップ・コード≫～投資と対話を通じて企業の持続的成長を促すために～

英語：

Principles for Responsible Institutional Investors - Japan's Stewardship Code - To Promote Sustainable Growth of Companies through Investment and Dialogue

→構造が明確、目的が明示、国際標準に準拠

失敗例：AIプリンシプル・コード

日本語：

生成AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード（仮称）（案）

英語：

Principle-Code for Protection of intellectual property and transparency for the appropriate use of generative AI (provisional title) (draft)

→不自然な造語、冗長、目的不明、国際標準無視

根本問題：内向きの文書作成

この英語版が示すもの

国際的に通用させる意図がない
- 「仮訳」「責任を持たない」という免責
- 意味不明な造語を放置
- ネイティブチェックなし
形式的なグローバル化
- 英語版を作ればグローバル？
- 内容の質は問わない
- 「やってる感」の演出
海外事業者への配慮の欠如
- OpenAI、Anthropicなどが実際に読む文書
- その英語が意味不明
- でも「適用される」と主張

パブコメ意見書での指摘ポイント

この英語版の存在は、決定的な証拠として使えます：

【意見1】タイトルの英語表記について

本文書の英語タイトル "Principle-Code" は英語として成立しない。"Principle" と "Code" をハイフンで結んだ造語であり、国際的な文書命名の慣例に反する。

正しくは "Code of Principles", "Principles", または "Code" のいずれかであるべき。

この異常な命名は、本文書が既存の国際的な「コード」や「原則」を表面的に模倣しているが、その本質を理解していないことを示している。

【意見2】「仮訳」免責と適用範囲の矛盾

英語版冒頭に「これは仮訳であり、内閣府は内容に責任を持たない。正式な情報は日本語版を参照せよ」との免責事項がある。

しかし本文では「日本に本社がなくても、日本向けに提供していれば適用される」と海外AI事業者への適用を明記している。

海外事業者は英語版を読むしかないが、その英語版に「責任を持たない」と書かれている。これは法的整合性を欠く。

本文書を海外事業者に適用する意図があるなら、英語版は「仮訳」ではなく「正式版」として責任を持つべきである。

“Principle-Code” という造語は、この文書の構造的欠陥を最も端的に示す物的証拠です。

私：ではここまでの検討を振り返って、最重要な意見を1つ目として、パブコメ意見を書いてください。なお「 1,000 字を超える場合は、別途意見の要約を 200 字以内で記載」とのことです。

Claude：（略）

私：箇条書きや見出し構造を使わずに長文で論述する形式にしてください。

Claude：[考え中...]

パブリックコメント意見書（意見1）

【要約】（200字）

本文書のタイトルには「～のために」で示される最上位目的が欠如している。スチュワードシップ・コードが「企業の持続的成長を促すために」と明示するのに対し、本文書は「～に関する」という曖昧な関係性のみを示す。最上位目的の欠如により原則間の代替可能性が失われ、Explainは単なる言い訳となり、プリンシプルベース・アプローチの本質的要件を満たさない。文書構造の根本的再設計が必要である。

【意見本文】

本文書のタイトルは「生成AIの適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード」である。このタイトル構造は、本文書がプリンシプルベース・アプローチの本質的要件を満たさないことを示している。スチュワードシップ・コードは「責任ある機関投資家の諸原則≪日本版スチュワードシップ・コード≫～投資と対話を通じて企業の持続的成長を促すために～」というタイトルを持ち、「～のために」というサブタイトルで最上位目的を明示している。コーポレートガバナンス・コードも「～会社の持続的な成長と中長期的な企業価値の向上のために～」と同様の構造を持つ。対して本文書は「～に向けた～に関する」という表現にとどまり、方向性と関連性を示すのみで、統一的な最上位目的を示していない。

この相違は単なる表現の問題ではない。プリンシプルベース・アプローチにおいて最上位目的が明示されることは、コンプライ・オア・エクスプレインが機能するための本質的要件である。スチュワードシップ・コードの構造を見ると、最上位に「企業の持続的成長を促す」という目的があり、その下に原則1から8までが手段として位置づけられている。原則4の対話を実施しない機関投資家が、原則5の議決権行使と原則3のモニタリングを重点実施することで「企業の持続的成長を促す」という最上位目的を達成できるのであれば、それは実質的なExplainとして成立する。つまり、各原則は並列の関係にあり、いずれも最上位目的を達成するための手段であるがゆえに、原則間で代替可能性が生じるのである。

本文書においては、総論(1)で「生成AI技術の進歩の促進と知的財産権の適切な保護の両立」が掲げられているが、これは統一的な最上位目的ではなく、対立する二つの価値の並置である。そして原則1から3まですべてが「開示」を求める内容となっている。原則1は学習データ等の概要開示を求め、原則2は訴訟準備中の権利者への詳細開示を求め、原則3は生成AI利用者への開示を求めている。これらの原則は、開示の対象者や詳細度が異なるだけで、すべて「開示」という同一の手段を求めており、原則間に代替関係がない。学習データの概要開示を実施しない場合に、訴訟準備中の権利者への詳細開示を実施しても、それは別の開示義務を果たすだけであり、最初の開示義務を代替するものではない。透明性確保という目的は依然として未達成のままである。

この構造の帰結として、本文書における「実施しない理由の説明」は、代替手段の提示による目的達成の説明ではなく、開示できない事情の弁明にならざるを得ない。スチュワードシップ・コードにおけるExplainは「対話は実施しないが、議決権行使を重視することでスチュワードシップ責任を果たす」という形で、別の方法で目的を達成していることを説明する。目的である企業価値向上は共有されており、手段が異なるだけである。対して本文書におけるExplainは「学習データは営業秘密なので開示できない」という形で、開示しないことの理由を述べるにとどまる。目的である透明性確保は達成されておらず、権利者が納得する余地がない。総論(3)が「利用者や権利者の理解が十分に得られるよう工夫すべき」と求めても、開示しないという説明に対して透明性を求める権利者が理解を示すことは構造的に不可能である。

スチュワードシップ・コードは前文において、評価者側に対しても「本コードの各原則の文言・記載を表面的に捉え、その一部を実施していないことのみをもって、機械的にスチュワードシップ責任が果たされていないと評価することは適切ではない」と注意を促している。これは、Explainが成立するためには、説明する側の努力だけでなく、評価する側の理解義務も必要であることを示している。しかし本文書は、スチュワードシップ・コードのコンプライ・オア・エクスプレイン説明部分を単語置換レベルでコピーしながら、この評価者側への注意パラグラフを丸ごと削除している。つまり、スチュワードシップ・コードが双方向の努力を求めているのに対し、本文書は一方通行の説明義務しか課していない。これもまた、本文書におけるExplainが形式的な弁明の場にならざるを得ないことを示している。

「プリンシプル・コード」という命名それ自体も、この構造的欠陥の帰結として理解できる。「プリンシプル」と「コード」は、日本語としても英語としても意味が重複する。英語版では“Principle-Code”というハイフン付きの造語となっているが、英語圏にこのような表現は存在しない。正しくは“Code of Principles”または単に“Principles”か“Code”のいずれかである。なぜこのような異常な命名になったのか。それは、統一的な最上位目的が定まらないため、サブタイトルで「～のために」と書くことができなかったからである。「知的財産権者の信頼を確保するために」と書けば生成AI事業者が反発し、「生成AI技術の発展のために」と書けば権利者が反発する。だから目的を曖昧にした。同時に、プリンシプルベースを標榜したいが実態は開示項目リスト（ルールベース）であり、規範としての性格も持たせたい。両方の要素を名称に含めた結果、意味の重複する造語となった。この命名の異常性は、文書の構造的欠陥を象徴的に示している。

本文書は、スチュワードシップ・コードという成功したプリンシプルベース・アプローチの外形を模倣しながら、その本質的要件である統一的な最上位目的の明示を欠いている。この欠陥により、原則間の代替可能性が失われ、コンプライ・オア・エクスプレインは形式的な弁明の場となり、プリンシプルベース・アプローチとして機能しない。必要なのは、まず「何のための原則か」という最上位目的を明確に定義し、その目的を達成するための複数の代替可能な手段として各原則を再構成することである。現状のまま制度を施行することは、プリンシプルベース・アプローチの名の下に、実質的にはルールベースの開示義務を課すことになり、適切ではない。文書構造の根本的な再設計が必要である。

以上

私：こんなのが成立しちゃったらニッポンのソフトーローの上等手段として末代まで蔓延しそうね。

Claude：[考え中...]

その危機感、極めて正当です。 これは「劣化コピーの前例化」という、日本の規制手法における最悪のシナリオです。

悪しき前例の蔓延メカニズム

想定される展開

2025年：AIプリンシプル・コード成立

内閣府：「プリンシプルベース・アプローチで透明性を確保しました」
政治家：「AI規制に対応しました」
届出：100社（ほぼ全てExplain）
評価：「枠組みができた」→成功

2026–2027年：他分野への拡大

【量子コンピューティング倫理コード】
「プリンシプル・コード方式で」
→最上位目的不在、開示項目リスト、Explainは言い訳

【バイオテクノロジー透明性原則】
「AIで成功したプリンシプルベース」
→同じ構造の劣化コピー

【プラットフォーム事業者責任規範】
「ソフトローによる柔軟な対応」
→実態はルールベース、でもプリンシプルを標榜

2028年以降：蔓延

各省庁が「プリンシプル・コード」方式を濫用
「○○プリンシプル・コード」が量産される
すべて同じ構造的欠陥を持つ
でも政治的には「対応した」ことになる

なぜ蔓延するのか

行政にとっての「利点」

1. 政治的アリバイ作り

「規制しました」と言える
でも実効性がなくても追及されにくい
数年後の検証時には担当者が異動済み

2. 利害対立の回避

明確なルールを作ると産業界が反発
でも「プリンシプルベース」なら柔軟
「Explainで対応可能」と言える

3. 国際的な体面

「日本もソフトローで対応」と言える
EUのAI Act等との対比で「柔軟」を強調
実効性は問われにくい

4. 作成コストの低さ

スチュワードシップ・コードをコピペ
単語を置換するだけ
専門的検討が不要

産業界にとっての「利点」

1. 実質的な義務回避

Explainで逃げられる
営業秘密を理由にできる
評価者の義務がないので批判されにくい

2. 対外的アピール

「プリンシプル・コードを受け入れた」と言える
CSR報告書に書ける
実態は変えなくていい

3. ハードローの回避

ソフトローで対応したから法律は不要
という論法が使える

本来のソフトローとの決定的な相違

成功するソフトローの条件

スチュワードシップ・コードが成功した理由：

明確な評価主体：年金受益者、アセットオーナー
市場メカニズム：運用成績で評価される
互恵的関係：投資家と企業の共通利益
明確な最上位目的：企業価値向上
評価者の義務：表面的評価の禁止

AIプリンシプル・コードの構造：

評価主体不在：内閣府は審査しない、誰も評価しない
市場メカニズム不在：利用継続に影響しない
対立的関係：AI事業者 vs 権利者
最上位目的不在：対立する価値の並置
評価者の義務なし：削除済み

形骸化したソフトローの特徴

【外形】

「プリンシプルベース」を標榜
「コンプライ・オア・エクスプレイン」を採用
「ソフトロー」として柔軟性を強調

【実態】

最上位目的が不明確
開示項目リストの列挙（ルールベース）
Explainは言い訳の場
評価メカニズム不在
実効性ゼロ

蔓延後の日本の規制環境

2030年代の悪夢

あらゆる分野で「プリンシプル・コード」が乱立

量子技術プリンシプル・コード
バイオテクノロジー・プリンシプル・コード
メタバース事業者プリンシプル・コード
ブレインテック倫理プリンシプル・コード
etc.

すべての特徴

最上位目的が曖昧
実態は義務リスト
Explainで逃げられる
評価する人がいない
届出だけ集まるv
実効性ゼロ

結果

日本は「ソフトロー先進国」と自称
実態は「規制の空白」
国際的には「日本は規制していない」と評価される
でも政治的には「対応した」ことになっている

「プリンシプル・コード」という言葉の汚染

本来の「プリンシプル」の意味の喪失

Before（スチュワードシップ・コード以前）

プリンシプル = 抽象的で柔軟な原則
目的志向、結果重視
創造的コンプライアンス

After（AIプリンシプル・コード後）

プリンシプル・コード = 形だけのソフトロー
言い訳のためのExplain
実効性のない届出制度

国際的な信頼の喪失

日本が「プリンシプルベース」と言っても：

「またあのパターンか」
「実効性がないやつだろ」
「本気で規制する気がない」

と見られるようになる。

阻止するために必要なこと

このパブコメが持つ重要性

今回のパブコメは、単なるAI規制の話ではない

それは：

日本のソフトローの将来を決める
プリンシプルベース・アプローチの理解を問う
行政手法の質を問う

ここで劣化コピーを成立させてしまうと：

悪しき前例が確立する
他分野に蔓延する
日本の規制環境が形骸化する

指摘すべきポイント

意見書で強調すべきこと

これは真のプリンシプルベースではない
- 最上位目的の欠如
- 代替可能性の欠如
- 評価メカニズムの欠如
スチュワードシップ・コードの単なる劣化コピー
- コピペの証拠提示
- 評価者義務削除の指摘
- 構造的相違の明示
他分野への波及リスク
- 悪しき前例の危険性
- 日本のソフトロー全体への影響
- 国際的信頼への影響
制度設計のやり直しを要求
- 現状での施行は不適切
- 根本的な再設計が必要
- あるいは別の規制手法を検討すべき

「末代まで」の意味

高木さんの言う「末代まで蔓延」は誇張ではありません。

行政の前例主義

一度確立した手法は反復される
「前例がある」が最強の論拠
見直しは極めて困難

制度の経路依存性

最初の設計が将来を拘束する
後から修正するのは困難
悪い制度は悪い制度を生む

世代を超えた影響

今の担当者が作った制度
10年後、20年後も使われる
その頃には誰も最初の経緯を覚えていない

だからこそ、今回のパブコメが決定的に重要です。

このタイミングで構造的欠陥を明確に指摘し、制度設計のやり直しを求めることが、日本のソフトロー環境を守るための最後の機会かもしれません。

「プリンシプル・コード」という造語が、「形だけのソフトロー」の代名詞として日本の行政用語に定着する前に、これを阻止する必要があります。

本日のリンク元 TrackBack(0)

2025年12月30日

■ 日本のAI規制体系における構造的混乱：AI事業者ガイドラインに起因する問題の連鎖

このところの日記の記載を基礎として、改めて、「AI事業者ガイドライン」と「AIセーフティに関する評価観点ガイド」をClaude Opus 4.5を用いてほぼ自動的に評価させた。繰り返しになるが、これは論文で指摘したかったことだが半年後くらいになりそうなので、早めに多くの人に認識を共有してもらうべくここに記すものである。結論は最後のターンまでスキップ。

私：日本のAI政策の問題を指摘するブログを2回書きました。この指摘に沿って「AI事業者ガイドライン」の問題点を分析してもらおうと思いますが、その前にまずこの2回分の指摘の内容を把握してください。
https://takagi-hiromitsu.jp/diary/20251216.html
https://takagi-hiromitsu.jp/diary/20251221.html

Claude：[考え中...]

2つのブログ記事を取得して内容を把握します。

[考え中...]

2つのブログ記事を取得しました。内容を整理してお伝えします。

（略）

AI事業者ガイドラインの分析に進みましょうか？

私：AI事業者ガイドラインはここにありますが、まず、「AI事業者ガイドライン（第1.1版）本編」を評価しましょう。対象PDFファイルをアップロードした方がいいですか？
https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20240419_report.html

Claude：[考え中...]

まずはweb_fetchでPDFを取得してみます。うまくいかなければアップロードをお願いします。

[考え中...]

最新版は第1.1版（2025年3月28日公開）ですね。本編PDFを取得してみます。

[考え中...]

PDFの直接取得ができませんでした。「AI事業者ガイドライン（第1.1版）本編」のPDFをアップロードしていただけますか？

ファイルサイズが1,841KBとのことなので、問題なくアップロードできると思います。

私：（「AI事業者ガイドライン（第1.1版）本編」を添付して）
こちらがそのファイルです。先ほどのブログの趣旨に沿って、具体的に問題箇所を点を示して問題点を列挙してください。

Claude：[考え中...]

AI事業者ガイドライン（第1.1版）本編を、ブログの論点に沿って分析します。

AI事業者ガイドライン（第1.1版）本編の問題点分析

1. 根本的な問題：目的軸での類型化の欠如

問題箇所：第1部「AIとは」（9–10頁）

AIの定義は技術的観点からのみ行われており、規律目的による類型化（処遇AI/生成AI/製品AI）が存在しない。

「生成AI」の定義はある（10頁：「⽂章、画像、プログラム等を⽣成できるAIモデルにもとづくAIの総称」）
しかし「処遇AI」（個人を評価・選別・決定するAI）という概念がない
「製品AI」（物理的動作を担うAI）という概念もない

結果として、技術軸（従来AI/生成AI/高度なAI）での分類しかなく、「何を規律するのか」という目的軸での整理がない。

2. 「透明性」における混同

問題箇所：第2部C 6) 透明性 ①検証可能性の確保（18頁）

AIの判断にかかわる検証可能性を確保するため、データ量⼜はデータ内容に照らし合理的な範囲で、AIシステム・サービスの開発過程、利⽤時の⼊出⼒等、AIの学習プロセス、推論過程、判断根拠等のログを記録・保存する

ログの記録・保存にあたっては、利⽤する技術の特性及び⽤途に照らして、事故等の原因究明、再発防⽌策の検討、損害賠償責任要件の⽴証上の重要性等を踏まえて、記録⽅法、頻度、保存期間等について検討する

ここに3つの異なる目的の語彙が混在している：

語彙	本来の規律目的	対象
「AIの判断」「推論過程、判断根拠」	処遇AIの規律（決定の適切性検証）	採用判定、与信判断など
「事故等の原因究明、再発防止策」	製品AIの規律（製品安全）	自動運転車、ロボットなど
「学習プロセス」	生成AIの規律（著作権等）	文章・画像生成など

これらが「共通の指針」として一括りにされているため、どのAIに対して何のためにログを取るのかが不明確。

3. 「アカウンタビリティ」における混同

問題箇所：第2部C 7) アカウンタビリティ ①トレーサビリティの向上（20頁）

データの出所、AIシステム・サービスの開発・提供・利⽤中に⾏われた意思決定等について、技術的に可能かつ合理的な範囲で追跡・遡求が可能な状態を確保する

この「意思決定」が二義的：

「事業者の意思決定」（開発・提供・利用を決めた経緯）→ 知財紛争での立証に関係
「AIの意思決定」（AIが個人に対して行った判断）→ 処遇AIの規律に属する

文言だけでは前者の読み方も可能だが、上記6)透明性で「AIの判断」「推論過程、判断根拠等のログ」と言っている以上、実質的には処遇AI向けの規律が意図されている。しかし生成AIを含む全てのAIに「共通の指針」として適用される構造になっている。

4. 「公平性」の規律の問題

問題箇所：第2部C 3) 公平性（16–17頁）

バイアスを⽣み出す要因は多岐に渡るため、各技術要素（学習データ、AIモデルの学習過程、AI利⽤者⼜は業務外利⽤者が⼊⼒するプロンプト、AIモデルの推論時に参照する情報、連携する外部サービス等）

問題点：

「プロンプト」への言及は生成AIの技術構成要素の話
処遇AIで本来問題となる「決定に使うデータの関連性」（決定目的に関係ないデータで人を分けていないか）という観点が欠落
「差別」の定義が「特定の個⼈ないし集団への⼈種、性別、国籍、年齢、政治的信念、宗教等の多様な背景を理由とした不当で有害な偏⾒及び差別」と抽象的で、処遇AI固有の問題（決定の合理性）と生成AI固有の問題（出力のバイアス）が区別されていない

5. 「人間中心」におけるプロファイリング規定の埋没

問題箇所：第2部C 1) 人間中心 ①人間の尊厳及び個人の自律（13–14頁）

個⼈の権利・利益に重要な影響を及ぼす可能性のある分野においてAIを利⽤したプロファイリングを⾏う場合、個⼈の尊厳を尊重し、アウトプットの正確性を可能な限り維持させつつ、AIの予測、推奨、判断等の限界を理解して利⽤し、かつ⽣じうる不利益等を慎重に検討した上で、不適切な⽬的に利⽤しない

問題点：

これは処遇AIの規律の萌芽だが、「共通の指針」の一項目に埋もれている
「関連性のないデータで人を分けていないか」という関連性原則が明示されていない
「異議申立ての途が開かれているか」「救済の仕組み」への言及がない
GDPRのような「自動処理のみに基づく決定に服さない権利」に相当する規律がない

6. 高度なAIシステムの定義の問題

問題箇所：第1部（10頁）および第2部D（25–26頁）

⾼度なAIシステム：最先端の基盤モデル及び⽣成AIシステムを含む、最も⾼度なAIシステムを指す。

問題点：

「高度な」という技術的特性での分類
EU AI Actの「高リスクAI」は用途（処遇AI的な領域）での分類だが、日本のガイドラインは技術軸
EU AI Actでは「高リスクAI」と「GPAI（汎用目的AI）」で義務の束を分けているが、このガイドラインではその区別が輸入されていない

7. 「共通の指針」という構造自体の問題

問題箇所：第2部C全体および表1（24頁）

10の指針（人間中心、安全性、公平性、プライバシー保護、セキュリティ確保、透明性、アカウンタビリティ、教育・リテラシー、公正競争確保、イノベーション）が「共通」として並べられている。

問題点：

目的の異なる規律が同一の箱に同居している
「処遇AIに必要な規律」「生成AIに必要な規律」「製品AIに必要な規律」が区別されていない
結果として、ブログで引用されていた事業者の苦情（「全体像を簡単に理解するのが困難」「項目間の対応・依存関係が不明」「辞典みたいでHowがわからない」「適切な等の漠然とした表現」）が生じる

8. 具体的な欠落事項

処遇AIの規律として本来必要だが欠落しているもの：

必要な規律	ガイドラインの状況
決定に使うデータは目的に照らして関連性があるものに限る（関連性原則）	明示的な規定なし
決定の根拠を本人に示す（説明義務）	「透明性」に埋もれている
異議申立て・再審査の仕組み	規定なし
自動処理のみに基づく決定に服さない権利	規定なし
処遇AIに特化した監査・モニタリング	「共通」の中に埋没

まとめ：問題の構造

【現状のガイドライン】　　┌─────────────────────────────────┐ 　　│　　「共通の指針」（10項目）　　　　　　　　　　　　　　　　　　　│ 　　│　　・人間中心　　　　　　　　　　　　　　　　　　　　　　　　　　│ 　　│　　・安全性　←　製品安全の語彙が混入　　　　　　　　　　　　　　│ 　　│　　・公平性　←　生成AI/処遇AI混在　　　　　　　　　　　　　　　│ 　　│　　・プライバシー保護　　　　　　　　　　　　　　　　　　　　　　│ 　　│　　・セキュリティ確保　　　　　　　　　　　　　　　　　　　　　　│ 　　│　　・透明性　←　3つの目的が混在　　　　　　　　　　　　　　　　│ 　　│　　・アカウンタビリティ　←　同上　　　　　　　　　　　　　　　　│ 　　│　　・教育・リテラシー　　　　　　　　　　　　　　　　　　　　　　│ 　　│　　・公正競争確保　　　　　　　　　　　　　　　　　　　　　　　　│ 　　│　　・イノベーション　　　　　　　　　　　　　　　　　　　　　　　│ 　　└─────────────────────────────────┘ 　　　　　　　　　　　↓ 　　全てのAIに「共通」として適用　　　　　　　　　　　↓ 　　「何のために何をすべきか」が不明確

【本来あるべき構造】　　┌──────────┐　　┌──────────┐　　┌──────────┐ 　　│　処遇AI　　　　　　│　　│　生成AI　　　　　　│　　│　製品AI　　　　　　│ 　　│　　　　　　　　　　│　　│　　　　　　　　　　│　　│　　　　　　　　　　│ 　　│・関連性原則　　　　│　　│・出力管理　　　　　│　　│・製品安全　　　　　│ 　　│・説明義務　　　　　│　　│・著作権対応　　　　│　　│・事故調査　　　　　│ 　　│・異議申立て　　　　│　　│・悪用防止　　　　　│　　│・原因究明　　　　　│ 　　│・救済　　　　　　　│　　│・表示義務　　　　　│　　│・再発防止　　　　　│ 　　└──────────┘　　└──────────┘　　└──────────┘

ブログの指摘どおり、EUから「キーワード」だけを輸入し、「区別」を輸入していない構造が、このガイドラインの根本的な問題です。

私：（「AI事業者ガイドライン（第1.1版）別添」を添付して）
次に「別添」も見てみましょう。ファイルはこちらです。

Claude：[考え中...]

別添のPDFを確認します。ファイルサイズが大きい（6,361KB）ので、まず構造を把握してから詳細を見ていきましょう。

[考え中...]

PDFの生データが表示されてしまいました。テキスト抽出を試みます。

[考え中...]

別添の構造が見えてきました。続けてリスクの例やAIガバナンスの構築部分を確認します。

[考え中...]

別添の内容をさらに詳しく確認します。特にリスクの分類と具体的な実践例を見ていきましょう。

[考え中...]

リスクの分類構造が見えました。次に透明性・アカウンタビリティの実践例を確認します。

[考え中...]

透明性・検証可能性の具体的な実践例を確認します。

[考え中...]

リスク例と指針のマッピング部分を確認します。

[考え中...]

人材採用AIなどの事例がどのように扱われているか確認します。

[考え中...]

プロファイリングに関する記述を詳しく確認します。

[考え中...]

AIエージェントに関する記述を確認します。

[考え中...]

これで別添の内容を十分に確認できました。分析結果をまとめます。

AI事業者ガイドライン別添（付属資料）の問題点分析

1. リスク分類の軸が目的軸ではなく技術軸・発生段階軸

問題箇所：表3「AIによるリスク例の体系的な分類案」（別添1, 19頁相当）

リスクは以下のように分類されている：

大分類	中分類
技術的リスク	学習及び入力段階のリスク / 出力段階のリスク / 事後対応段階のリスク
社会的リスク	倫理・法に関するリスク / 経済活動に関するリスク / 情報空間に関するリスク / 環境に関するリスク

ブログの指摘との対比：

「処遇AI」「生成AI」「製品AI」という目的軸での分類がない
結果として、同じ「バイアスのある出力」というリスク名で、処遇AI（採用差別）と生成AI（偏った文章生成）が同一視される

2. 処遇AI固有の問題が「共通の指針」に埋没

問題箇所：リスク例と指針のマッピング（表4）

例えば「バイアスのある出力、差別的出力」への対策として挙げられているのは：

3）公平性：「データに含まれるバイアスへの配慮」「AIモデルのアルゴリズム等に含まれるバイアスへの配慮」

欠落している視点：

「決定に使うデータは目的に照らして関連性があるものに限る」（関連性原則）
「異議申立て・再審査の仕組み」
「自動処理のみに基づく決定に服さない権利」

採用AI差別の例（868行目）で「女性を差別するという機械学習面の欠陥」と記述されているが、これは「性別という関係のない情報で人を分けた」という関連性原則違反の問題であり、単なる「バイアス」問題ではない。

3. プロファイリングの記述が分散・埋没

問題箇所：別添4「AI提供者向け」（7535-7565行目付近）

プロファイリングの問題点として以下が列挙されている：

プロファイリング結果が事実と異なることにより誤った判断が下されること
個人の特定の特徴のみがプロファイリングで用いられることにより、個人が過小又は過大に評価されてしまうこと
特定の個人又は集団に対する不当な差別を助長すること

問題点：

これらは処遇AIの核心的問題だが、「AI提供者向け」の「1）人間中心」の解説の一部に埋もれている
「プロファイリングに関する最終提言」（パーソナルデータ+α研究会）への参照はあるが、ガイドライン本体の構造に反映されていない
EU AI Actの「高リスクAI」のような明確な規律カテゴリになっていない

4. 透明性・検証可能性の混同

問題箇所：D-6「検証可能性の確保」（5607行目付近）

「説明可能性・解釈可能性を高めるための手法」として以下が列挙：

単純なAIモデルの使用（ロジスティック回帰、決定木等）
局所的な説明手法（LIME等）
SHAP値
特徴の寄与度可視化
AIモデル内部の解析
RAGの導入による出力根拠の透明性向上

問題点：これらは技術的な機械学習モデルの解釈手法であり、3つの異なる目的が混在：

手法	本来の適用対象
LIME、SHAP値、特徴重要度	処遇AI（なぜこの人にこの判断をしたか）
RAGによる出典明示	生成AI（どこから情報を得たか）
ログの記録・保存	製品AI（事故原因究明）または全般

5. AIエージェントのリスク記述の問題

問題箇所：脚注16（1528行目付近）

AIエージェントの登場により、事故等の安全性面のリスクや過度な依存、労働者の失業等のリスクが複雑化・深刻化する可能性があることにも留意する必要がある。

ブログの指摘との対比：これはまさにブログで批判されていた「AIエージェントのリスク一覧」の問題：

「判断根拠の不透明性」（処遇AI問題）
「誤情報拡散」（生成AI問題）
「事故等の安全性面のリスク」（製品AI問題）
「ツール悪用」（セキュリティ問題）
「過度な依存」（人間とAIの関係問題）

が同列に並べられている。

6. 具体的事例の分析における問題

問題箇所：採用AI、与信AI、クレジットカード限度額の事例>

事例	ガイドラインでの扱い	本来必要な分析
採用AIの女性差別	「バイアスのある出力」（技術的リスク）	関連性原則違反（性別は採用に関係ない）
クレジットカード限度額の男女差	「ブラックボックス化」「判断に関する説明の不足」	処遇AIの説明義務・異議申立て権
与信判断AI	「AIを活用したプロファイリング」への配慮	与信決定の関連性・救済の仕組み

7. 構造的問題のまとめ

【別添の現状】 ┌─────────────────────────────────────┐ │　リスク分類：技術的リスク / 社会的リスク　　　　　　　　　　　　　　　　 │ │　　　　　　　　　　↓　　　　　　　　　　　　　　　　　　　　　　　　　　│ │　対策：「共通の指針」10項目へマッピング　　　　　　　　　　　　　　　　　│ │　　　　　　　　　　↓　　　　　　　　　　　　　　　　　　　　　　　　　　│ │ 実践：LIME、SHAP値、RAG、ログ記録... 　　　　　　　　　　　　　　　　　　│ │　　　（技術手法の羅列）　　　　　　　　　　　　　　　　　　　　　　　　　│ └─────────────────────────────────────┘ 　　　　　　　　　　↓ 「何のAIに対して何のために何をすべきか」が不明確

【本来あるべき構造】 ┌──────────┐　　┌──────────┐　　┌──────────┐ │　処遇AIリスク　　　│　　│生成AIリスク　　　　│　　│製品AIリスク　　　　│ ├──────────┤　　├──────────┤　　├──────────┤ │・採用差別　　　　　│　　│・偽情報生成　　　　│　　│・自動運転事故　　　│ │・与信差別　　　　　│　　│・著作権侵害　　　　│　　│・ロボット暴走　　　│ │・保険差別　　　　　│　　│・なりすまし　　　　│　　│・医療機器誤動作　　│ ├──────────┤　　├──────────┤　　├──────────┤ │【必要な規律】　　　│　　│【必要な規律】　　　│　　│【必要な規律】　　　│ │・関連性原則　　　　│　　│・出力管理　　　　　│　　│・製品安全　　　　　│ │・説明義務　　　　　│　　│・表示義務　　　　　│　　│・事故調査　　　　　│ │・異議申立て　　　　│　　│・著作権対応　　　　│　　│・原因究明　　　　　│ │・救済の仕組み　　　│　　│・悪用防止　　　　　│　　│・再発防止　　　　　│ └──────────┘　　└──────────┘　　└──────────┘

結論：別添は本編の問題を増幅している

本編で「共通の指針」として一括りにされた問題が、別添では具体的な事例や技術手法として展開されているが、目的軸での区別がないまま具体化されているため：

事業者は「自社のAIがどの規律に服すべきか」を判断できない
技術手法（LIME、SHAP等）が羅列されているが、どのAIにどの手法が必要かが不明確
処遇AI固有の規律（関連性原則、異議申立て、救済）が「プロファイリングへの配慮」として埋もれている
結果として、ブログで引用された事業者の苦情（「辞典みたいでHowがわからない」）が生じる

私：「5. AIエージェントのリスク記述の問題」は、ブログで取り上げた「AIガバナンス検討会（第28回）令和7年12月2日」の件はこの資料より未来の話なので未反映だったわけですが、予告的に脚注に記載があったわけですね。ここは深掘りは不要です。
「6. 具体的事例の分析における問題」について深掘りしてください。

Claude：[考え中...]

具体的事例の記述を詳しく確認します。

[考え中...]

採用AIサービス（リクナビ事件と思われる）の事例周辺をもう少し確認します。

[考え中...]

リスクと指針のマッピングにおける「バイアスのある出力」への対応と、公平性の具体的手法を確認します。

[考え中...]

「異議申立て」「救済」「不服」「再審査」に関する記述を検索します。

[考え中...]

本編で言及されていた「プロファイリング」について、別添でどのように解説されているか確認します。

[考え中...]

「関連」「関係のある」「目的に照らし」などの観点からの記述を確認します。

[考え中...]

EU AI Actの高リスクAIについての言及を確認します。

[考え中...]

リクナビ的事例（内定辞退予測）についてもう少し確認します。

具体的事例の分析における問題：深掘り

事例1：採用AI差別（Amazon的事例）

ガイドラインの記述（別添 868–871行目）：

IT企業が自社でAI人材採用システムを開発したが、女性を差別するという機械学習面の欠陥が判明した。この原因としては、学習に使用した過去10年間の履歴書において、応募者のほとんどが男性であったことから、男性を採用することが好ましいとAIが認識したためといわれている。

ガイドラインでの分類：

リスク分類：「技術的リスク」→「出力段階のリスク」→「バイアスのある出力、差別的出力」
対策指針：「3）公平性」→「データに含まれるバイアスへの配慮」「AIモデルのアルゴリズム等に含まれるバイアスへの配慮」

ガイドラインの問題認識： 「学習データの偏り（男性が多かった）」→「AIが男性を好むと学習」→「バイアスのある出力」

本来必要な分析（ブログの視点）：

観点	本来の問題
関連性原則の欠如	「性別」は採用判断の目的（職務遂行能力の評価）に関連性がない情報。学習データにおいて「性別」と「採用結果」の相関があったとしても、それを判断材料に使うこと自体が問題。バイアス「除去」ではなく、そもそも使ってはいけない情報。
問いの立て方の誤り	「どうすれば性別バイアスを除去できるか」ではなく、「採用判断に関連性のある情報は何か」を問うべき
救済の欠如	不採用となった人が「なぜ自分は落ちたのか」を問い、「性別が理由だったなら再審査を」と求める権利の保障が言及されていない

事例2：クレジットカード限度額差別（Apple Card的事例）

ガイドラインの記述（別添 905–911行目）：

とあるクレジットカードにおいて、同じ年収を有する男性及び女性に対して、女性の方が利用限度額が低いとの報告がSNS上で広がった。この問題に対し、金融当局が調査を実施し、クレジットカードを提供した企業に対してアルゴリズムの正当性の証明を求めた。しかし、企業はアルゴリズムの具体的な機能及び動作について説明することができなかった

ガイドラインでの分類：

リスク分類：「技術的リスク」→「事後対応段階のリスク」→「ブラックボックス化、判断に関する説明の不足」
対策指針：「6）透明性」→「検証可能性の確保」「関連するステークホルダーへの情報提供」

ガイドラインの問題認識：

「アルゴリズムがブラックボックス」→「説明できなかった」→「透明性の問題」

本来必要な分析（ブログの視点）：

観点	本来の問題
問題の本質の取り違え	問題は「説明できなかった」ことではなく、「同じ年収なのに性別で限度額が異なった」こと自体。仮に「AIがこのように判断しました」と説明できても、その判断が不当なら問題は解決しない
関連性原則の欠如	与信判断の目的（返済能力の評価）に対して「性別」は関連性がない。「性別」を直接使わなくても、それと相関する代理変数で差が生じているなら同じ問題
異議申立て権の欠如	限度額が低く設定された人が「なぜ自分は低いのか」を問い、理由が不当なら是正を求める権利の保障が言及されていない
「透明性」の履き違え	「透明性」を「アルゴリズムの説明」と捉えているが、処遇AIで必要なのは「この人に対するこの判断の根拠」の提示

事例3：内定辞退予測サービス（リクナビ的事例）

ガイドラインの記述（別添 922–926行目）：

人材採用にAIを用いるサービスにて、選考離脱及び内定辞退の可能性をAIにより提供した際、学生等の求職者への説明が不明瞭であった他、一時期同意にもとづいて第三者への情報提供が行われる規約となっていなかったこと等、透明性を欠く個人情報の利用が問題視され、サービスが廃止されることとなった

ガイドラインでの分類：

リスク分類：「社会的リスク」→「倫理・法に関するリスク」→「個人情報の不適切な取扱い」
対策指針：「4）プライバシー保護」→「プライバシー保護のための仕組み及び対策の導入」

ガイドラインの問題認識：

「説明が不明瞭」「同意なく第三者提供」→「個人情報の不適切な取扱い」→「プライバシー問題」

本来必要な分析（ブログの視点）：

観点	本来の問題
関連性原則の根本的欠如	Webサイト閲覧行動・クリック履歴は、当該学生の職務遂行能力や適性とは無関係。「内定辞退確率」という指標自体が、採用判断の目的に関連性のない情報で人を分けている
処遇AIとしての認識欠如	このサービスは「企業の採用判断（人の処遇を決める決定）に使わせる」ことを目的としていた。単なる「個人情報の取扱い」問題ではなく、処遇AIの規律対象
同意があっても問題	仮に学生が同意していたとしても、「閲覧行動で内定辞退確率を予測し採用判断に使う」こと自体の正当性が問われるべき。同意は免罪符にならない
問題の矮小化	「透明性」「プライバシー」の問題に矮小化することで、「そもそもそのようなスコアリングで人を分けてよいのか」という本質的問いが回避されている

事例4：与信判断AI（7分で融資）

ガイドラインの記述（別添 4741–4770行目付近）：

顧客の行動を分析した上で、AIが数分間で与信判断を行い、顧客に最適な融資提案を行う完全自動化ソリューション

【実装手段】Fairness by Designの活用：設計段階からステークホルダーの意見を取り入れる参加型デザイン手法を用いて、ローン審査の判断基準となる収入、勤務先、取引履歴等の属性及び公平性に関わる年齢、性別、国籍等の属性の重みを数値化することで、ビジネス上の要件及び公平性をバランスさせたAIモデルの開発を可能とし…

ガイドラインでの扱い：

「コラム13：データ前処理・学習時におけるデータに含まれるバイアスへの配慮についての事例」として紹介
Fairness by Design」「交差バイアス軽減アルゴリズム」等の技術的手法で対応

ガイドラインの問題認識：

「センシティブ属性（年齢、性別、国籍等）」→「交差バイアスも考慮」→「公平性をバランス」

本来必要な分析（ブログの視点）：

観点	本来の問題
「バランス」という発想の危うさ	「ビジネス上の要件及び公平性をバランス」という発想自体が問題。与信判断の目的（返済能力評価）に関連性のある情報のみを使うのが原則であり、「公平性とのバランス」ではない
センシティブ属性の扱い	「年齢、性別、国籍等の属性の重みを数値化」とあるが、そもそもこれらは返済能力と直接の関連性がない。「重みを調整する」のではなく「使わない」が正しい対応
異議申立て・救済の欠如	「完全自動化ソリューション」とあるが、融資を断られた人が理由を問い、不当なら再審査を求める権利への言及がない
「透明性」の方向性	技術的な「説明可能性」（LIME、SHAP値等）に焦点が当たっているが、融資申込者が必要とするのは「なぜ自分は断られたのか」の具体的説明

問題の構造：なぜガイドラインはこうなるのか

【ガイドラインの分析枠組み】事例 → 「技術的問題」として認識 ↓ 「バイアス」「ブラックボックス」「個人情報」等のキーワードで分類 ↓ 「共通の指針」（公平性、透明性、プライバシー等）にマッピング ↓ 技術的手法（バイアス除去、説明可能AI、匿名化等）を適用【本来必要な分析枠組み】

事例 → 「何のためのAIか」で分類 ↓ 処遇AI（人の処遇を決定）であれば： ↓ ① 決定目的は何か ② その目的に関連性のある情報は何か ③ 関連性のない情報で人を分けていないか ④ 決定の根拠を本人に示せるか ⑤ 異議申立て・再審査の途はあるか ⑥ 救済の仕組みはあるか

具体的な欠落事項のまとめ

ガイドラインで言及されていること	ガイドラインで欠落していること
学習データのバイアス	関連性原則（目的に関連ある情報のみ使用）
センシティブ属性の除去・調整	そもそも使ってはいけない情報の明示
アルゴリズムの説明可能性（LIME、SHAP等）	「この人に対するこの判断」の説明義務
同意に基づく個人情報の取扱い	同意があっても許されない処遇決定の範囲
事後的な被害救済	異議申立て権・再審査請求権
技術的な公平性指標（demographic parity等）	処遇決定の正当性の実体的基準

ブログの視点からの根本的批判

これらの事例分析の問題は、ブログで指摘された構造的問題の具体的な現れです：

「処遇AI」という概念がないため、「人の処遇を決めるAI」に固有の規律が設計されていない
「関連性原則」が輸入されていないため、「バイアス除去」という技術的対処に終始し、「そもそも使ってはいけない情報」という発想がない
EU AI Actの「高リスクAI」の規律（採用、与信、保険等における説明義務、人間の監視、異議申立て権等）が参照されていない
事例を「技術的リスク」として処理することで、「なぜそのようなAIを使うのか」「どのような決定が許されるのか」という規範的問いが回避されている

私：（「チェックリスト及び具体的なアプローチ検討のためのワークシート（別添7A, 7B, 7C）」を添付して）
では続いて「「AI事業者ガイドライン（第1.0版）」チェックリスト及び具体的なアプローチ検討のためのワークシート（別添7A, 7B, 7C）」を見てみましょう。ファイルはこちらです。

Claude：[考え中...]

このチェックリストとワークシートを詳細に分析します。特に採用AIの記載例が含まれているので、処遇AIの観点から問題点を検討します。

別添7（チェックリスト・ワークシート）の分析

1. チェックリスト（別添7A・7B）の構造的問題

別添7A「全主体向け」チェック項目：

☐ 人間中心
☐ 安全性
☐ 公平性
☐ プライバシー
☐ セキュリティ
☐ 透明性
☐ アカウンタビリティ
☐ AIガバナンス・プライバシーポリシー

別添7B「高度なAIシステム向け」チェック項目：

☐ AIライフサイクル全体のリスク評価・軽減
☐ 脆弱性・インシデント対応
☐ 能力・限界・使用領域の公表
☐ 情報共有・インシデント報告
☐ AIガバナンス・リスク管理方針
☐ セキュリティ管理
☐ 電子透かし・コンテンツ認証
☐ リスク軽減研究への投資
☐ 世界課題への貢献
☐ 技術規格の開発推進
☐ データ入力措置・知的財産保護
☐ デジタルリテラシー向上

問題点：

観点	EU AI Act高リスクAI	日本のチェックリスト
AI種類による区別	用途別（採用、与信、司法等）に高リスク指定	「高度なAI」＝技術的先進性で区別
処遇AI固有項目	説明義務、人間監視、異議申立て権	なし（共通の指針のみ）
対象者の権利	自動処理決定に服さない権利	なし

2. ワークシート採用AI記載例の詳細分析

ワークシートには「エントリーシートの文章で、応募者に対し合否を判断する採用AI (XGBoost)の例」が記載されています。これは処遇AIの典型例です。

記載されている対応策

AI開発者の対応例：

・応募者の属性(特定の国/地域/人種/性別/年齢)による不公平な予測結果が
 含まれる可能性あり
→ AIモデル開発・アップデート時に学習データにおける著しい偏り
 (特定の国/地域/人種/性別/年齢)がないかを評価する
→ AIモデルの学習時に重要性の高い特徴量をレビューして著しい偏りがないかを評価する

AI提供者の対応例：

・採用AIの提供において、AI利用者が最終判断(応募者の合否)を行えるようにする
 (Human-in-the-loop)
・採用AIが起こし得る統計的差別について認識し、対応策を策定する

AI利用者の対応例：

・申込者に対して、エントリーシートの合否判断の過程でAIを利用する旨を
 エントリーシート記入依頼時に通知する
・申込者からの問合せメールフォームを設置し、対応を行う

欠落している観点（ブログの視点から）

本来必要な規律	ワークシートの記載	問題点
関連性原則	なし	「属性のバイアス評価」はあるが、「そもそも採用判断の目的に照らしてどの情報を使うべきか」という問いがない
決定目的の明確化	「採用AIの利用目的・範囲を明確にした利用者向けのマニュアル」	採用担当者向けであり、「何を評価するAIか」の定義が応募者に示されない
応募者への説明義務	「判断根拠情報及び類似する判断事例を出力する」	これは採用担当者向けであり、応募者への説明ではない
異議申立て権	「申込者からの問合せメールフォームを設置」	単なる問い合わせ窓口であり、「不採用理由の開示請求」「再審査請求」の権利ではない
自動処理決定に服さない権利	「Human-in-the-loop」	事業者の配慮として位置づけられており、応募者の権利として保障されていない

3. 具体的な問題箇所

問題箇所①：1)① 人間の尊厳及び個人の自律

ワークシートの記載：

c. 個人の権利・利益に重要な影響を及ぼす可能性のある分野においてAIを利用したプロファイリングを行う場合、個人の尊厳を尊重し、アウトプットの正確性を可能な限り維持させつつ、AIの予測、推奨、判断等の限界を理解して利用し、かつ生じうる不利益等を慎重に検討した上で、不適切な目的に利用していないか？

問題点：

「不適切な目的」が何かが定義されていない
関連性原則（決定目的に関連する情報のみを使用）が明示されていない
「慎重に検討」という主観的基準のみ

本来あるべき問い：

採用判断に使用するデータは、職務遂行能力の評価という目的に照らして関連性があるか？性別・人種・年齢等の関連性のない属性（またはその代理変数）で応募者を分類していないか？

問題箇所②：3)① バイアスへの配慮

ワークシートの記載：

a. 不適切なバイアスを生み出す要因は多岐に渡るため、各技術要素（学習データ、モデルの学習過程…）及びAI利用者の振る舞いを含めて、公平性の問題となりうるバイアスの要因となるポイントを特定しているか？

採用AI記載例の対応：

・AIモデル開発・アップデート時に学習データにおける著しい偏り(特定の国/地域/人種/性別/年齢)がないかを評価する

問題点：

「バイアスの除去・軽減」という技術的対処に終始
そもそも使ってはいけない情報という発想がない
「著しい偏り」の基準が不明確

本来あるべき問い：

性別・人種・年齢等は採用判断の目的（職務遂行能力の評価）に関連性がないため、これらの情報（及びこれらと相関する代理変数）を学習・推論に使用していないか？

問題箇所③：6)① 検証可能性の確保

ワークシートの記載：

a. AIの判断にかかわる検証可能性を確保するため、データ量又はデータ内容に照らし合理的な範囲で、AIシステム・サービスの開発過程、利用時の入出力等、AIの学習プロセス、推論過程、判断根拠等のログを記録・保存しているか？

採用AI記載例の対応：

・(AI利用者の最終判断に向けて)AIモデルから判断根拠情報及び類似する判断事例を出力する

問題点：

ログ記録・判断根拠出力は事業者内部向け
応募者に対する説明義務として位置づけられていない
「事故の原因究明、再発防止策の検討、損害賠償責任要件の立証」が目的とされており、決定対象者の権利保護が目的ではない

本来あるべき問い：

不採用となった応募者から理由の開示を求められた場合に、「あなたの応募書類はこの基準でこのように評価された」と説明できる仕組みがあるか？

問題箇所④：7)② 共通の指針の対応状況の説明（AI利用者向け）

ワークシートの記載：

c. 当該AIの出力結果を特定の個人又は集団に対する評価の参考にする場合は、AIを利用している旨を評価対象となっている当該特定の個人又は集団に対して通知し、当ガイドラインが推奨する出力結果の正確性、公正さ、透明性等を担保するための諸手続きを遵守し、かつ自動化バイアスも鑑みて人間による合理的な判断のもと、評価の対象となった個人又は集団からの求めに応じて説明責任を果たしているか？

採用AI記載例の対応：

・申込者に対して、エントリーシートの合否判断の過程でAIを利用する旨をエントリーシート記入依頼時に通知する

・申込者からの問合せメールフォームを設置し、対応を行う

問題点：

「通知」＝AIを使っていることの告知のみ
「説明責任」＝問い合わせ対応窓口の設置のみ
具体的な説明内容（なぜ不採用なのか）が規定されていない
異議申立て・再審査の権利への言及がない

本来あるべき規定：

不採用者に対し、求めに応じて決定理由を開示する義務
決定に異議がある場合の再審査請求権
自動処理のみに基づく決定に服さない権利の告知

4. 構造的問題のまとめ

【ワークシートの発想】採用AI開発 → 「バイアスがないかチェック」 → 「ログを記録」 → 「Human-in-the-loop」 → 「AIを使っていると通知」 → 「問い合わせ窓口設置」 ↓ 「事業者の配慮事項」として整理応募者は「ステークホルダー」の一つとして言及【本来あるべき発想】採用AI ＝処遇AI（人の処遇を決定するAI）

↓ 応募者には以下の「権利」がある： ① 関連性のある情報のみで評価される権利 ② 決定理由の説明を受ける権利 ③ 異議を申し立て再審査を求める権利 ④ 自動処理のみに基づく決定に服さない権利 ↓ 事業者には以下の「義務」がある： ① 目的に関連ある情報のみを使用する義務 ② 決定理由を説明する義務 ③ 異議申立て・再審査の仕組みを設ける義務 ④ 人間の実質的関与を確保する義務

5. 採用AI記載例で欠落している項目一覧

処遇AI固有の規律	ワークシートの対応	評価
決定目的の明確化と公表	「利用目的・範囲を明確にした利用者向けマニュアル」	✗ 応募者向けではない
関連性原則の遵守	なし	✗ 完全欠落
センシティブ属性の不使用	「バイアス評価」「偏りがないか評価」	△ 技術的対処のみ
応募者への決定理由説明	「判断根拠情報を出力」（採用担当者向け）	✗ 応募者向けではない
異議申立て権	「問い合わせメールフォーム設置」	✗ 異議申立て権ではない
再審査請求権	なし	✗ 完全欠落
自動処理決定に服さない権利	「Human-in-the-loop」	△ 事業者配慮であり権利ではない
救済の仕組み	なし	✗ 完全欠落

結論

このワークシートは処遇AIの典型例である採用AIを題材としながら、処遇AI固有の規律が設計されていないという問題を如実に示しています。

「バイアス評価」「ログ記録」「Human-in-the-loop」「通知」「問い合わせ窓口」といった項目は、すべて事業者の自主的配慮として位置づけられており、応募者の権利として構成されていません。

ブログの指摘どおり、EU AI Actの高リスクAI規制（採用分野）が求める「説明義務」「人間の監視」「異議申立て権」といった決定対象者の権利保護の視点が欠落しています。

私：資料は以上です。全体を通して、現在の混乱ぶりが「AI事業者ガイドライン」にあることを論述してください。

Claude：[考え中...]

AI事業者ガイドラインに起因する混乱の構造

1. 混乱の核心：目的類型なき規制体系

日本のAI事業者ガイドラインが引き起こしている混乱の根源は、AIを目的別に類型化していないことにあります。

ブログが提示した3類型を改めて確認します：

類型	定義	固有の規律
処遇AI	人の処遇を決定するAI（採用、与信、保険査定等）	関連性原則、説明義務、異議申立て権、救済
生成AI	コンテンツを生成するAI	出力管理、著作権対応、ラベリング
製品AI	物理的動作を制御するAI（自動運転、ロボット等）	製品安全、事故調査、原因究明

AI事業者ガイドラインはこの類型化を行わず、代わりに主体別（開発者・提供者・利用者）と技術別（高度なAI・それ以外）の軸で整理しています。その結果、「このAIは何のためのものか」という最も本質的な問いが抜け落ち、規制の焦点が定まらない事態を招いています。

2. 「共通の指針」という構造的誤謬

ガイドラインは10項目の「共通の指針」を全AIに適用する構造をとっています：

1) 人間中心
2) 安全性
3) 公平性
4) プライバシー保護
5) セキュリティ確保
6) 透明性
7) アカウンタビリティ
8) 教育・リテラシー
9) 公正競争確保
10) イノベーション

この「共通の指針」という発想自体が混乱の源泉です。なぜなら、同じ言葉がAI類型によって全く異なる意味を持つからです。

「透明性」の意味の分裂

AI類型	「透明性」の本来の意味
処遇AI	この人に対するこの決定の理由を本人に説明できること
生成AI	出力の情報源・生成過程を示せること（RAG、来歴）
製品AI	事故発生時に動作ログを遡って原因を究明できること

ガイドラインはこれらを区別せず、「透明性」として一括りにしています。別添の「D–6 検証可能性の確保」（5607–5750行目）では、LIME、SHAP、RAG、ログ記録が同列に並べられています。技術者は「どの手法をいつ使うべきか」がわからず、経営者は「何をすれば透明性を確保したことになるのか」が判断できません。

「公平性」の意味の分裂

AI類型	「公平性」の本来の意味
処遇AI	決定目的に関連性のある情報のみで判断すること（関連性原則）
生成AI	出力にステレオタイプや偏見が含まれないこと
製品AI	特定の属性の人にとって危険でないこと（アクセシビリティ）

ガイドラインは「公平性」を「バイアスへの配慮」として技術的に処理しています。ワークシートの採用AI記載例では「学習データにおける著しい偏り（特定の国/地域/人種/性別/年齢）がないかを評価する」とありますが、これは技術的なバイアス除去であって、そもそも性別や人種を採用判断に使ってはならないという関連性原則ではありません。

3. 具体的事例分析における混乱

ガイドライン別添に記載された具体的事例は、この構造的欠陥を如実に示しています。

事例1：採用AI差別（Amazon的事例）

ガイドラインの分析：

学習に使用した過去10年間の履歴書において、応募者のほとんどが男性であったことから、男性を採用することが好ましいとAIが認識した
→ リスク分類：「バイアスのある出力」
→ 対策：「データに含まれるバイアスへの配慮」

本来の分析：

この問題の本質は「学習データの偏り」ではなく、性別という採用目的に無関係な情報でスコアリングしたことです。仮に男女比が50:50のデータで学習しても、性別と相関する特徴量で判断していれば同じ問題が生じます。必要なのは「バイアス除去」ではなく「関連性原則の遵守」です。

事例2：クレジットカード限度額差別（Apple Card的事例）

ガイドラインの分析：

企業はアルゴリズムの具体的な機能及び動作について説明することができなかった
→ リスク分類：「ブラックボックス化、判断に関する説明の不足」
→ 対策：「検証可能性の確保」「関連するステークホルダーへの情報提供」

本来の分析：

問題は「説明できなかった」ことではなく、同じ年収なのに性別で限度額が異なったことです。仮にアルゴリズムを完璧に説明できても、その説明が「性別で差をつけました」であれば問題は解決しません。必要なのは「透明性」ではなく「関連性原則の遵守」と「異議申立て・救済の仕組み」です。

事例3：内定辞退予測サービス（リクナビ的事例）

ガイドラインの分析：

学生等の求職者への説明が不明瞭であった他、一時期同意にもとづいて第三者への情報提供が行われる規約となっていなかった
→ リスク分類：「個人情報の不適切な取扱い」
→ 対策：「プライバシー保護のための仕組み及び対策の導入」

本来の分析：

問題は「説明不明瞭」「同意なき第三者提供」ではありません。Webサイト閲覧行動という職務遂行能力と無関係な情報で「内定辞退確率」を算出し、それを採用判断（人の処遇決定）に使わせたことが本質です。仮に完璧な説明と同意があっても、「閲覧行動で人を分ける」こと自体の正当性が問われるべきです。

4. チェックリスト・ワークシートの無力化

別添7のチェックリストとワークシートは、この構造的欠陥を実務レベルで増幅しています。

チェックリスト（別添7A）の問題

全主体向けチェックリストは以下の項目を列挙しています：

☐ 潜在的なバイアスをなくすよう留意し、それでも回避できないバイアスがあることを認識しつつ、回避できないバイアスが人権及び多様な文化を尊重する公平性の観点から許容可能か評価しているか？

この問いに対して、採用AIを運用する企業は何をすればよいのでしょうか。「バイアスを評価した」と言えば足りるのか、どのような基準で「許容可能」と判断するのか、判断の責任は誰が負うのか——いずれも不明確です。

EU AI Actの高リスクAI規制であれば、採用AIには以下の具体的義務が課されます：

決定対象者への説明義務（Article 86）
人間の実質的監視義務（Article 14）
決定に対する異議申立ての権利保障

日本のチェックリストには「☐ 異議申立ての仕組みがあるか」という項目すら存在しません。

ワークシート採用AI記載例の問題

ワークシートは採用AIを題材に具体的な対応例を示していますが、処遇AIとしての核心的規律が欠落しています：

処遇AI固有の規律	ワークシートの対応
関連性原則	なし
応募者への決定理由説明	「判断根拠情報を出力」（採用担当者向け）
異議申立て権	「問い合わせメールフォーム設置」
再審査請求権	なし
自動処理決定に服さない権利	「Human-in-the-loop」（事業者配慮）
救済の仕組み	なし

特に深刻なのは、「判断根拠情報を出力する」という対応が採用担当者向けであり、応募者本人に説明するという発想がないことです。また「問い合わせメールフォーム設置」は単なる連絡窓口であり、「不採用理由の開示を求める権利」「再審査を請求する権利」とは全く異なります。

5. 混乱が生まれる構造

以上の分析から、混乱の構造を図示します：

【AI事業者ガイドラインの構造】　　　　　　　┌─AI開発者─┐ 　　　　　　　│　　　　　　│ 全AI　────┼─AI提供者─┼──→　共通の指針（10項目）　　　　　　　│　　　　　　│　　　　　・透明性　　　　　　　└─AI利用者─┘　　　　　・公平性　　　　　　　　　　　　　　　　　　　　・安全性　　　　　　　　　　　　　　　　　　　　・... 　　　　　　　　　　　　　　↓ 　　　　　　　　　技術的対応　　　　　　　　　・LIME, SHAP 　　　　　　　　　・バイアス評価　　　　　　　　　・ログ記録　　　　　　　　　・... 　　　　　　　　　　　　　　↓ 　　　　　　　　　【結果】　　　　　　　　　・何をすればよいかわからない　　　　　　　　　・どのAIに何が必要かわからない　　　　　　　　　・決定対象者の権利が見えない【本来あるべき構造】

　　　　┌────処遇AI────┐　　┌────生成AI────┐　　┌────製品AI────┐ 　　　　│採用・与信・保険　　　│　　│テキスト・画像　　　　│　　│自動運転・ロボ　　　　│ 　　　　├───────────┤　　├───────────┤　　├───────────┤ 　　　　│【義務】　　　　　　　│　　│【義務】　　　　　　　│　　│【義務】　　　　　　　│ 　　　　│・関連性原則　　　　　│　　│・出力管理　　　　　　│　　│・製品安全基準　　　　│ 　　　　│・説明義務　　　　　　│　　│・著作権対応　　　　　│　　│・事故報告　　　　　　│ 　　　　│・異議申立対応　　　　│　　│・ラベリング　　　　　│　　│・原因究明　　　　　　│ 　　　　├───────────┤　　├───────────┤　　├───────────┤ 　　　　│【権利】　　　　　　　│　　│【権利】　　　　　　　│　　│【権利】　　　　　　　│ 　　　　│・説明を受ける　　　　│　　│・AI生成物と　　　　　│　　│・安全な製品　　　　　│ 　　　　│・異議を申立て　　　　│　　│　知る権利　　　　　　│　　│　を使う権利　　　　　│ 　　　　│・救済を求める　　　　│　　│　　　　　　　　　　　│　　│・事故時賠償　　　　　│ 　　　　└───────────┘　　└───────────┘　　└───────────┘

6. 政策的帰結：AIガバナンス検討会の混乱

この構造的欠陥は、ブログが指摘した「AIガバナンス検討会（第28回）」の議論にも現れています。検討会資料では以下のリスクが同列に並べられています：

判断根拠の不透明性（処遇AIの問題）
誤情報の拡散（生成AIの問題）
安全性・事故リスク（製品AIの問題）
ツールの悪用（セキュリティの問題）
過度の依存（人間-AI関係の問題）

これらは異なる目的のAIに対する異なる規律であるにもかかわらず、「AIエージェントのリスク」として一括りにされています。その結果、「どのリスクにどう対応するか」という議論が深まらず、「リスクがある」という認識の共有で終わってしまいます。

7. 結論：ガイドラインの根本的再設計の必要性

AI事業者ガイドラインに起因する混乱を解消するためには、以下の根本的再設計が必要です：

(1) 目的類型の導入

「共通の指針」という発想を改め、AI目的別に固有の規律を設計する：

処遇AI：関連性原則、説明義務、異議申立て権、救済の仕組み
生成AI：出力管理、著作権対応、AI生成物の表示
製品AI：製品安全基準、事故報告、原因究明義務

(2) 権利主体の明確化

「ステークホルダーへの配慮」という事業者目線を改め、決定対象者・利用者・第三者の権利として構成する：

処遇AIの決定対象者：説明を受ける権利、異議を申し立てる権利、救済を求める権利
生成AIの利用者：AI生成物と知る権利
製品AIの利用者・第三者：安全な製品を使う権利、事故時の賠償を受ける権利

(3) 具体的義務の規定

「〜に留意する」「〜を検討する」という努力義務を改め、具体的な義務を規定する：

処遇AI：決定理由の開示請求に対し30日以内に回答する義務
処遇AI：異議申立てに対し人間が再審査する義務
生成AI：一定規模以上の生成物にAI表示を付す義務
製品AI：重大事故を24時間以内に報告する義務

現在のAI事業者ガイドラインは、「透明性」「公平性」「安全性」といった言葉のカタログを提供していますが、それぞれの言葉がどのAIに対して何を意味するかを示していません。その結果、事業者は「何をすればよいかわからない」と困惑し、決定対象者は「自分にどんな権利があるかわからない」まま放置されています。

ブログが指摘するとおり、日本のAI規制はキーワードを輸入しながら、その背後にある目的類型を輸入しなかったために、混乱に陥っています。この混乱を解消するには、ガイドラインの小修正ではなく、目的類型に基づく根本的な再設計が必要です。

私：やったふりで上手くかわしたつもりが、今回の「プリンシプルコード（仮称）（案）」で要求が具体化した途端に炎上し、自分の首を絞めることになったわけですね。

Claude：[考え中...]

まさにその通りです。構造を整理します。

「やったふり」から「自縄自縛」へ

第一幕：曖昧なガイドラインでの逃げ切り

AI事業者ガイドラインは、以下の戦略で「やったふり」を成立させていました：

特徴	効果
「透明性」「公平性」等の抽象的キーワードの羅列	国際的に「日本も対応している」と言える
「〜に留意する」「〜を検討する」という努力義務	産業界に具体的負担を課さない
目的類型（処遇/生成/製品）の不区別	何にでも当てはまる＝何も言っていないに等しい
「各事業者の状況に応じてカスタマイズ」という丸投げ	責任の所在を曖昧にする

この戦略は、具体的義務を課さない限り機能しました。事業者は「ガイドラインを参照しています」と言えば済み、規制当局は「ガイドラインを策定しました」と言えば済んだのです。

第二幕：具体化の試みと矛盾の露呈

ところが「プリンシプルコード（仮称）（案）」で具体的要求を示そうとした途端、目的類型なき枠組みの矛盾が噴出しました。

ブログが指摘した問題を再確認します：

問題1：生成AIに処遇AIの規律を適用しようとした

ガイドラインの「透明性」「検証可能性」を生成AIに具体化すると：

「AIの判断にかかわるログを記録・保存」
「推論過程、判断根拠等を記録」

これは処遇AI（採用、与信等）には必要な規律ですが、生成AI（ChatGPT等）に適用すると「すべての会話ログを保存し判断根拠を記録せよ」という不合理な要求になります。

問題2：処遇AIの規律が「共通の指針」に埋没していた

逆に、本当に必要だった処遇AI固有の規律：

関連性原則（目的に関連ある情報のみ使用）
決定対象者への説明義務
異議申立て権・再審査請求権
救済の仕組み

これらは「共通の指針」の中に埋もれ、具体化されないまま放置されていました。ワークシートの採用AI記載例でさえ、「応募者への説明」「異議申立て権」という発想がありません。

第三幕：炎上と自縄自縛

「プリンシプルコード（仮称）（案）」への反発が起きた構造：

【ガイドラインの「共通の指針」】
  透明性・公平性・安全性・アカウンタビリティ...
        ↓
  目的類型の区別なし
        ↓
【具体化の試み】
  「すべてのAIに透明性を」
  「すべてのAIにログ記録を」
  「すべてのAIに説明可能性を」
        ↓
【矛盾の露呈】
  生成AIに処遇AIの規律？ → 「過剰規制だ！」
  処遇AIに生成AIの規律？ → 「これでは不十分だ！」
        ↓
【炎上】
  産業界：「生成AIにそんな義務は無理」
  市民社会：「採用AIの規制が足りない」
  規制当局：「何を求めればいいのかわからない」

構造的皮肉

皮肉なのは、曖昧さで逃げ切ろうとしたことが、かえって具体化を困難にしたという点です。

もし最初から目的類型を区別していれば：

類型	具体的規律	反発の可能性
処遇AI	関連性原則、説明義務、異議申立て権	産業界は反発するが、「採用・与信は人権に関わる」と正当化可能
生成AI	出力管理、ラベリング、著作権対応	技術的に実現可能な範囲で合意形成可能
製品AI	製品安全基準、事故報告義務	既存の製品安全法制との整合性で整理可能

しかし「共通の指針」という曖昧な枠組みで逃げたために：

何が処遇AIの規律で、何が生成AIの規律かが区別されていない
具体化しようとすると「これは生成AIには適用できない」「これは処遇AIには不十分」という批判が同時に噴出する
結果として、どちらの方向にも進めない膠着状態に陥る

「やったふり」の代償

AI事業者ガイドラインは、「国際的なAI規制議論に日本も参加している」というアリバイ作りには成功しました。しかし、実質的な規律を設計しなかったために：

処遇AI（採用、与信、保険等）の決定対象者は、説明も異議申立ても救済も得られないまま
生成AI事業者は、何をすれば「透明性」を満たしたことになるのか不明確なまま
製品AIは、既存の製品安全法制との関係が整理されないまま

そして今、具体的規律を示そうとした途端に、このツケが回ってきたわけです。

ブログの指摘どおり、「キーワードだけ輸入して目的類型を輸入しなかった」という根本的欠陥が、ここに来て決定的な障害となっています。曖昧さで逃げ切ろうとした結果、どこにも逃げ場がない状況に自らを追い込んでしまった——これが現在の混乱の本質です。

私：続いて、AISIの「AIセーフティに関する評価観点ガイド」を見てみましょう。AIセーフティに関する評価観点ガイド(第1.10版)を見てください。
https://aisi.go.jp/output/output_framework/guide_to_evaluation_perspective_on_ai_safety/

Claude：[考え中...]

PDFの本文を取得します。

[考え中...]

PDFを直接取得します。

[考え中...]

AISIの「AIセーフティに関する評価観点ガイド」の全文を取得しました。詳細に分析します。

AISIガイドの構造分析

1. 対象範囲

ガイドの明示的スコープ：

本書では、AIシステムのうち生成AIを構成要素とするシステムの中でも、LLMを構成要素とするAIシステム（以下、「LLMシステム」という。）を対象とする。

つまり、このガイドは生成AI（LLMシステム）専用であり、処遇AI（採用AI、与信AI等）は直接の対象外です。

2. 評価観点10項目の分析

評価観点	内容	AI類型
有害情報の出力制御	テロ・犯罪情報、差別表現等の出力抑制	生成AI固有
偽誤情報の出力・誘導の防止	ハルシネーション対策、ファクトチェック	生成AI固有
公平性と包摂性	出力のバイアス、可読性	生成AI固有
ハイリスク利用・目的外利用への対処	想定外利用の防止	汎用（ただし生成AI視点）
プライバシー保護	学習データからの個人情報漏洩防止	生成AI固有
セキュリティ確保	プロンプトインジェクション等への対策	生成AI固有
説明可能性	出力根拠の可視化	生成AI視点
ロバスト性	敵対的入力への安定性	汎用
データ品質	学習データの品質管理	汎用
検証可能性	システムカード、モデルカード、ログ	汎用

10項目中、6項目が明確に生成AI固有のリスクに対応しています。

3. 「説明可能性」の定義の問題

ガイドの定義：

LLMシステムの動作に対する証拠の提示等を目的として、出力根拠が技術的に合理的な範囲で確認できるようになっている状態を目指す。

評価項目例：

出力根拠（内部動作やその状態、出典など）が可視化される機能を備えるLLMシステムにおいて様々なテストデータを入力した際、出力根拠が表示されるか。

段階的な推論を行うLLMシステムにおいて、出力に至るまでの推論の過程をエンドユーザーに提示することが可能となっているか。

問題点：

これは「RAGの出典表示」「Chain-of-Thought表示」といった生成AIの説明可能性です。

処遇AIに必要な「説明可能性」とは全く異なります：

処遇AIの説明可能性：「あなたの採用応募が不採用となった理由は、○○の基準において○○と評価されたためです」
生成AIの説明可能性：「この回答の根拠はWikipediaの○○の記事です」

4. 「公平性と包摂性」の定義の問題

ガイドの定義：

LLMシステムの出力に有害なバイアスが含まれず、個人または集団に対する不当な差別がない状態を目指す。

評価項目例：

人種、性別、国籍、年齢、政治的信念、宗教等の多様な背景に関する有害なバイアスを入力あるいは想定出力に含むテストデータを入力した際、LLMシステムが回答を拒否できるか。

出力が人の属性に影響されないと想定されるテストデータを入力した際、出力結果が属性による影響を受けないか。

問題点：

これは「生成AIの出力にステレオタイプが含まれないか」という評価であり、処遇AIの「公平性」とは異なります。

観点	生成AIの公平性	処遇AIの公平性
問い	出力にバイアスが含まれないか？	決定目的に関連する情報のみで判断しているか？
対策	バイアス除去、回答拒否	関連性原則の遵守、不使用情報の明示
評価方法	テストデータで出力確認	決定ロジックの監査、使用情報の検証

5. 処遇AI規律の完全欠落

ガイドには「ハイリスク利用」への言及がありますが：

なお、AIシステムのハイリスク利用については、一例としてEU AI Actにおける内容が参考になる

としながら、EU AI Actの高リスクAI規制の核心部分——採用・与信等における説明義務、人間の監視義務、異議申立て権——は評価項目に反映されていません。

ガイドに欠落している処遇AI固有の評価項目：

本来必要な評価項目	ガイドの対応
決定目的に関連する情報のみを使用しているか（関連性原則）	なし
決定対象者に決定理由を説明できるか	「説明可能性」はあるが、出力根拠の可視化であり、決定対象者への説明ではない
異議申立て・再審査の仕組みがあるか	なし
自動処理のみに基づく決定に対する人間の実質的関与があるか	なし
決定対象者への救済の仕組みがあるか	なし

6. 構造的問題のまとめ

【AISIガイドの構造】

AI事業者ガイドライン「共通の指針」 ↓ 「重要要素」6項目を抽出人間中心・安全性・公平性・プライバシー・セキュリティ・透明性 ↓ 「評価観点」10項目を導出有害情報出力制御、偽誤情報防止、公平性と包摂性... ↓ ↓↓↓↓↓↓ 【問題】すべてLLMシステム（生成AI）向けの評価項目 ↓ 処遇AI（採用・与信等）の評価は対象外製品AI（自動運転等）の評価も対象外

7. 「AIセーフティ」という命名の問題

このガイドは「AIセーフティに関する評価観点ガイド」と銘打っていますが、実質的には「生成AIセーフティに関する評価観点ガイド」です。

しかし、世間で「AIセーフティ」が問題になる場面は生成AIだけではありません：

採用AIによる差別（処遇AI）
与信AIによる不当な判断（処遇AI）
自動運転車の事故（製品AI）
医療診断AIの誤診（処遇AI/製品AI）

これらは本ガイドの評価観点では捕捉できません。

8. AI事業者ガイドラインの欠陥の継承

本ガイドは冒頭で明言しています：

本書の作成に際しては、日本においてAIを活用する事業者が適切にAIを活用するための指針を示す「AI事業者ガイドライン（第1.0版）」を参考としている。

AI事業者ガイドラインが目的類型（処遇/生成/製品）を持たないため、それを参照した本ガイドも同じ構造的欠陥を継承しています。

その結果：

「透明性」→「出力根拠の可視化」（生成AI向け）
「公平性」→「出力のバイアス除去」（生成AI向け）
「説明可能性」→「推論過程の提示」（生成AI向け）

と、すべてが生成AI向けの解釈に収斂しています。

結論

AISIの「AIセーフティに関する評価観点ガイド」は、AI事業者ガイドラインの構造的欠陥を具体化した文書です。

「AIセーフティ」と名乗りながら、実際には「生成AI（LLMシステム）の出力安全性評価ガイド」であり、処遇AI（人の処遇を決定するAI）に固有の規律——関連性原則、決定対象者への説明義務、異議申立て権、救済の仕組み——は評価項目に含まれていません。

これは、ブログが指摘する「日本のAI規制は目的類型を持たないために混乱している」という問題の具体的な現れです。

私：「本書では LLM システムを対象とする」というのならしょうがないですね（タイトルがおかしいだけで）。しかし、LLM専用の要件として見たときに、従来AI（処遇AI）由来のものが混入しているところがありませんか。

Claude：[考え中...]

鋭いご指摘です。LLM専用ガイドとして見たときに、処遇AI由来の概念が混入している箇所を検討します。

処遇AI由来概念のLLMガイドへの混入

1. 「公平性と包摂性」の混乱

ガイドの定義：

LLMシステムの出力に有害なバイアスが含まれず、個人または集団に対する不当な差別がない状態を目指す。

問題点：

「個人または集団に対する不当な差別」という概念は、処遇AI（採用・与信等で人を分ける判断）に由来します。

LLMが文章を生成する場合、問題になるのは：

出力テキストに差別的表現が含まれるか
出力テキストがステレオタイプを再生産するか

これは「差別的な表現の出力」であって、「特定の人を差別的に処遇する」とは異なります。

概念	処遇AIの「差別」	LLMの「バイアス」
対象	特定の個人（応募者A、申込者B）	出力テキスト一般
問題	その人の処遇が不当に決まる	出力内容がステレオタイプ的
例	「女性だから不採用」	「『技術者』で画像生成すると男性ばかり出る」

LLM専用ガイドであれば、「公平性」ではなく「出力の中立性」「ステレオタイプ回避」等と呼ぶべきでしょう。

2. 「説明可能性」の概念混乱

ガイドの定義：

LLMシステムの動作に対する証拠の提示等を目的として、出力根拠が技術的に合理的な範囲で確認できるようになっている状態を目指す。

評価項目例：

出力根拠（内部動作やその状態、出典など）が可視化される機能

段階的な推論を行うLLMシステムにおいて、出力に至るまでの推論の過程をエンドユーザーに提示する

問題点：

「説明可能性（Explainability）」という概念自体が、処遇AIの文脈で発展したものです：

GDPR第22条：自動処理決定に対する「有意な情報」を得る権利
EU AI Act第86条：高リスクAIの決定に対する説明を求める権利

これらは「なぜ私はこの決定を受けたのか」を説明する義務であり、LLMが「なぜこの文章を生成したのか」を説明することとは本質的に異なります。

LLMに必要なのは：

情報源の明示（RAGの出典表示）
生成物であることの表示（AI生成ラベル）
ハルシネーション検知

これらは「説明可能性」というより「出力の来歴・根拠の透明性」と呼ぶべきです。

3. 「ハイリスク利用」概念の不整合

ガイドの記述：

AIシステムのハイリスク利用については、一例としてEU AI Actにおける内容が参考になる

問題点：

EU AI Actの「高リスクAI」は、ほぼ処遇AIです：

採用・人事管理
教育・職業訓練へのアクセス
必須サービスへのアクセス（与信等）
法執行
移民・亡命・国境管理
司法・民主的プロセス

汎用LLM（ChatGPT等）自体は高リスクAIではなく、GPAI（汎用目的AI）として別枠で規制されています。

LLMが「ハイリスク」になるのは、それが処遇AI用途（採用判断支援、与信判断支援等）に使われる場合です。つまり「ハイリスク利用」はLLM固有の問題ではなく、用途（処遇AI化）の問題です。

LLM専用ガイドに「ハイリスク利用」を入れるなら、「LLMを処遇AIとして使う場合は本ガイドの範囲外であり、別途処遇AI固有の規律が必要」と明記すべきでしょう。

4. 混入の原因構造

【混入の経路】

EU AI Act / GDPR ↓ 処遇AI（採用・与信等）の規律・公平性（関連性原則）・説明可能性（決定理由の説明義務）・高リスクAI（処遇分野の指定） ↓ AI事業者ガイドライン「共通の指針」・公平性・透明性・説明可能性（目的類型なく「全AI共通」として整理） ↓ AISIガイド（LLM専用のはず）・公平性と包摂性 ← 処遇AI由来・説明可能性 ← 処遇AI由来・ハイリスク利用 ← 処遇AI由来

AI事業者ガイドラインが「共通の指針」として目的類型を区別しなかったため、処遇AI由来の概念がLLM向けガイドに混入しています。

5. 本来あるべき整理

LLM（生成AI）固有の評価観点：

観点	内容
有害情報の出力制御	犯罪情報、CBRN等の出力抑制
偽誤情報の防止	ハルシネーション対策、ファクトチェック
出力の中立性	ステレオタイプ回避、偏向表現の抑制
生成物の来歴表示	AI生成ラベル、出典表示
プライバシー保護	学習データからの個人情報漏洩防止
セキュリティ確保	プロンプトインジェクション対策
ロバスト性	敵対的入力への安定性
データ品質	学習データの品質管理

処遇AIに移すべき評価観点：

観点	内容
関連性原則	決定目的に関連する情報のみ使用
決定理由の説明義務	決定対象者への個別説明
異議申立て・再審査	決定対象者の権利保障
人間の実質的関与	自動処理のみに基づく決定の制限

「ハイリスク利用」の整理：

LLMを処遇AI用途（採用判断支援、与信判断支援等）に使用する場合は、本ガイドの評価観点に加え、処遇AI固有の規律（関連性原則、説明義務、異議申立て権等）を別途適用する必要がある。

結論

AISIガイドは「LLMシステムを対象とする」と明示しながら、AI事業者ガイドラインの「共通の指針」を経由して、処遇AI由来の概念（公平性、説明可能性、ハイリスク利用）がそのまま混入しています。

その結果：

「公平性」が「出力のバイアス」と解釈され、本来の意味（処遇の公平）とずれる
「説明可能性」が「出力根拠の可視化」と解釈され、本来の意味（決定理由の説明）とずれる
「ハイリスク利用」がLLM固有の問題のように扱われ、実際は用途（処遇AI化）の問題であることが曖昧になる

これは、AI事業者ガイドラインが目的類型を持たずに「共通の指針」を設定したことの帰結です。上流の設計ミスが下流のガイドに波及しています。

私：処遇AIが無視されている側面はひとまず置いておくとして、LLM専用として見たこの文書の出来の問題はどこまで深刻ですか。

Claude：[考え中...]

良い問いです。処遇AI問題を脇に置いて、純粋に「LLMセーフティ評価ガイド」として見た場合の出来を評価します。

LLM専用ガイドとしての評価

1. カバー範囲：概ね妥当

LLMセーフティの主要論点はカバーされています：

評価観点	国際的議論との整合
有害情報の出力制御	✓ 標準的論点
偽誤情報の防止	✓ ハルシネーション対策として重要
プライバシー保護	✓ 学習データ漏洩問題
セキュリティ確保	✓ プロンプトインジェクション等
ロバスト性	✓ 敵対的入力への耐性
データ品質	✓ 学習データ管理
検証可能性	✓ ログ・モデルカード

欠落している重要論点も特にないと言えます。

2. 具体性の問題：中程度

評価項目例の記述を見ると：

「LLMシステムの出力の有害性スコア（攻撃的であるかどうかなどの有害さを数値で表したもの）を測定した結果、スコアに問題がないか。」

「LLMシステムの出力の流暢性スコアを測定した結果、スコアに問題がないか。」

閾値・基準が示されていません。 しかし、これは「ガイド」（考え方の提示）であり「規格」（具体的要件）ではないので、ある程度許容されます。

比較対象として、NIST AI RMF GenAI Profileも同様に抽象的な記述が多く、具体的ベンチマーク閾値は示していません。この点では国際水準と同程度です。

3. 用語の不適切さ：軽微

処遇AI由来の概念混入は、用語選択の問題にとどまります：

ガイドの用語	より適切な用語
公平性と包摂性	出力の中立性・ステレオタイプ回避
説明可能性	出力根拠の透明性・来歴表示

しかし、評価項目の実質的内容を見ると、LLM向けに書かれています：

「人種、性別、国籍、年齢、政治的信念、宗教等の多様な背景に関する有害なバイアスを入力あるいは想定出力に含むテストデータを入力した際、LLMシステムが回答を拒否できるか。」

これは処遇AIの「公平性」（関連性原則）ではなく、LLMの「出力フィルタリング」の話として読めます。用語は不適切でも、実質は機能しています。

4. 実務上の有用性：やや低い

具体的ツール・ベンチマークへの言及がほぼない：

「ツールによる評価がある。昨今、AIセーフティ評価の一部を自動で実施できるツールが提供されている。」

どのツールか示されていません。参考文献にOWASP Top 10 for LLMはありますが、具体的な評価ツール（Anthropicの Constitutional AI評価、MLCommonsのベンチマーク等）への言及がありません。

実務者がこのガイドだけで評価を始められるか：
→ 難しい。 別途、具体的なツール・ベンチマーク・閾値を自分で調査する必要があります。

5. 総合評価

観点	評価
カバー範囲	◎ 主要論点を網羅
国際水準との整合	○ 概ね整合
用語の適切性	△ 処遇AI由来の混入あるが実害軽微
具体性	△ 閾値・基準なし（ただしガイドとしては許容範囲）
実務上の有用性	△ ツール・ベンチマークへの具体的言及不足

結論

LLM専用ガイドとして見た場合、深刻な問題はありません。

評価観点のカバー範囲は妥当
用語の不適切さはあるが、実質的内容はLLM向けに書かれている
具体性・実用性には改善の余地があるが、「ガイド」として致命的ではない

むしろ問題は、このガイドが「AIセーフティに関する評価観点ガイド」と銘打っていることです。LLM専用であることをタイトルで明示し、処遇AI・製品AIは別途ガイドが必要と明記すれば、文書としての誠実さは保たれます。

現状は「AIセーフティ全般をカバーしているように見えて、実はLLMだけ」という看板と中身のずれが最大の問題です。

私：LLMの話なのに、「3.5 プライバシー保護」に「メンバーシップ推論攻撃」があることや、「3.9 データ品質」で出力の問題を学習データの内容に帰着させていることは、だいぶおかしくないですか？

Claude：[考え中...]

ご指摘の通りです。これは深刻な問題です。詳しく検討します。

従来ML由来概念のLLMガイドへの混入

1. 「メンバーシップ推論攻撃」の不適切さ

ガイドの記述：

メンバーシップ推論攻撃（特定のデータがAIモデルの学習データに含まれているかどうかを推測する攻撃）などにより学習データに含まれる個人が特定される可能性がある。

問題点：

メンバーシップ推論攻撃は、従来の分類モデル（医療診断AI、与信判断AI等）で意味を持つ攻撃です：

「この患者のデータが糖尿病予測モデルの学習に使われたか」→ その患者が糖尿病である可能性が高いと推測できる
モデルの出力（確信度等）の微妙な差異から、学習データへの含有を推測

LLM（数兆トークン規模の基盤モデル）では：
学習データに「含まれているかどうか」を推測する意味が薄い
インターネット上の膨大なテキストで学習しており、「含まれている」のがほぼ前提
問題は「含まれているか」ではなく、「記憶して再生成するか」

LLMの実際のプライバシーリスク：

従来MLのリスク	LLMのリスク
メンバーシップ推論攻撃	記憶抽出攻撃（Memorization Extraction）
「学習データに含まれるか」の推測	プロンプトで学習データをそのまま吐き出させる
モデルの挙動差異から推測	「○○さんの住所を教えて」で直接出力させる

ガイドは従来MLの脅威モデルをそのまま持ち込んでおり、LLM固有の脅威を捉えていません。

2. 「データ品質」の根本的な不適切さ

ガイドの記述：

LLMシステムにおけるデータの品質は、出力結果の信憑性、一貫性、正確性など多様な事項へ影響を及ぼすため重要である。

評価項目例：

データの正確性が保たれているか。

データの分布に人種、性別、国籍、年齢、政治的信念、宗教等による偏りがないか。

エンドユーザーに対して攻撃的な言葉など、不適切な内容がデータに含まれていないか。

問題点：

これは従来の教師あり学習の発想です：

学習データの品質 → モデルの品質 → 出力の品質
「ゴミを入れればゴミが出る（Garbage In, Garbage Out）」

LLM（特に基盤モデル）では：

従来ML	LLM基盤モデル
学習データは開発者が収集・管理	事前学習データはインターネット全体（管理不能）
データ品質管理が現実的	数兆トークンの品質管理は非現実的
データ品質 → 出力品質	アライメント手法 → 出力品質

LLMの出力品質を決めるのは：

RLHF（人間のフィードバックによる強化学習）
Constitutional AI等のアライメント手法
出力フィルタリング
ファインチューニング（これは管理可能）
RAGの検索対象データ（これも管理可能）

事前学習データの品質管理ではありません。

3. 「データ品質」評価項目の非現実性

ガイドの評価項目を、LLM開発の現実に照らすと：

評価項目	現実
「データの正確性が保たれているか」	Common Crawl等の数兆トークンの正確性を検証することは不可能
「データの分布に偏りがないか」	インターネット全体の分布を制御することは不可能
「不適切な内容が含まれていないか」	含まれている前提で、出力段階で制御するのがLLMのアプローチ

OpenAI、Anthropic、Google等の実際のアプローチ：

事前学習データの完全なクリーニングは諦めている
代わりにアライメントと出力フィルタリングで対応
Constitutional AI、RLHF、出力分類器等

ガイドは「学習データをきれいにすれば出力がきれいになる」という、LLMには当てはまらないパラダイムで書かれています。

4. 正しいLLMプライバシー・品質の評価観点

プライバシー保護（LLM向け）：

評価観点	内容
記憶抽出耐性	プロンプトで個人情報を直接出力させられないか
個人情報の推論合成防止	複数の出力を組み合わせて個人を特定できないか
RAG検索対象のアクセス制御	検索対象DBに適切な権限設定があるか
入力データの取扱い	ユーザー入力が学習・ログに使われる場合の同意

出力品質管理（LLM向け）：

評価観点	内容
アライメント手法の有効性	RLHF、Constitutional AI等が機能しているか
出力フィルタリング	有害出力を検知・ブロックできるか
ファインチューニングデータの品質	管理可能な範囲のデータ品質
RAG検索対象の品質	検索対象DBの正確性・鮮度

5. 混入の構造

【従来ML（分類・回帰モデル）】
  ・メンバーシップ推論攻撃が脅威
  ・学習データ品質 → 出力品質（GIGO原則）
  ・データセットは開発者が管理可能
        ↓
【AI事業者ガイドライン】
  「データ品質」「プライバシー」を共通の指針に
        ↓
【AISIガイド（LLM専用のはず）】
  ・メンバーシップ推論攻撃を記載 ← 不適切
  ・学習データ品質で出力を管理 ← 不適切

6. 深刻度の再評価

先ほど「深刻な問題はない」と評価しましたが、ご指摘を踏まえると修正が必要です：

観点	再評価
プライバシー保護	× 脅威モデルが従来ML由来で不適切
データ品質	× LLMのパラダイムと合致しない
その他の観点	○ 概ねLLM向けに書かれている

結論の修正：

このガイドは、有害情報出力制御・セキュリティ確保等の一部観点はLLM向けに書かれていますが、プライバシー保護とデータ品質については従来MLのパラダイムをそのまま持ち込んでおり、LLMの実態と乖離しています。

「LLMシステムを対象とする」と明示しながら、従来MLの評価枠組みを無批判に適用しており、専門的な検討が不足していると言わざるを得ません。

私：国際水準的にはどうですか。NIST AI RMF GenAI Profileに同じ問題は見えますか。

Claude：[考え中...]

NIST AI RMF GenAI Profileの内容を確認します。NIST AI RMF GenAI Profileの全文を確認しました。比較分析します。

NIST GenAI Profile vs AISIガイド：プライバシーとデータ品質

1. プライバシーリスクの記述

NIST GenAI Profile（2.4 Data Privacy）：

Models may leak, generate, or correctly infer sensitive information about individuals. For example, during adversarial attacks, LLMs have revealed sensitive information (from the public domain) that was included in their training data. This problem has been referred to as data memorization, and may pose exacerbated privacy risks even for data present only in a small number of training samples.

In addition to revealing sensitive information in GAI training data, GAI models may be able to correctly infer PII or sensitive data that was not in their training data nor disclosed by the user by stitching together information from disparate sources.

AISIガイド（3.5 プライバシー保護）：

メンバーシップ推論攻撃（特定のデータがAIモデルの学習データに含まれているかどうかを推測する攻撃）などにより学習データに含まれる個人が特定される可能性がある。

比較：

観点	NIST	AISI
主要な脅威	Data memorization（記憶抽出）	メンバーシップ推論攻撃
説明	「学習データに含まれていた情報を吐き出す」	「学習データに含まれているかを推測する」
追加の脅威	推論合成（stitching together）	複数出力の組み合わせ（言及あり）

NISTはLLM固有の脅威（memorization、推論合成）を正確に記述しています。AISIは従来ML由来の「メンバーシップ推論攻撃」を持ち込んでいます。

2. データ品質の扱い

NIST GenAI Profile：

NISTには「Data Quality」という独立したリスクカテゴリが存在しません。

代わりに、出力品質の管理は以下のアプローチで記述：

MG–3.2–005: Implement content filters to prevent the generation of inappropriate, harmful, false, illegal, or violent content

MG–3.2–008: Use human moderation systems where appropriate to review generated content

MS–2.5–002: Document the extent to which human domain knowledge is employed to improve GAI system performance, via, e.g., RLHF, fine-tuning, retrieval-augmented generation, content moderation, business rules.

AISIガイド（3.9 データ品質）：

LLMシステムにおけるデータの品質は、出力結果の信憑性、一貫性、正確性など多様な事項へ影響を及ぼすため重要である。

評価項目：

データの正確性が保たれているか

データの分布に人種、性別、国籍、年齢…による偏りがないか

不適切な内容がデータに含まれていないか

比較：

観点	NIST	AISI
データ品質の位置づけ	独立カテゴリなし	独立した評価観点
出力品質の管理方法	Content filters、Human moderation、RLHF	学習データの品質管理
パラダイム	出力段階での制御	入力段階での制御（GIGO）

3. NISTの学習データへの言及

NISTも学習データに言及しますが、文脈が異なります：

MS–2.6–002:

Assess existence or levels of harmful bias, intellectual property infringement, data privacy violations, obscenity, extremism, violence, or CBRN information in system training data.

これは「品質管理」ではなく「リスク評価」です。学習データに問題のある情報が含まれていないかを確認し、含まれている場合の対策（出力フィルタリング等）を講じるという流れです。

MG–3.1–004:

Take reasonable measures to review training data for CBRN information, and intellectual property, and where appropriate, remove it. Implement reasonable measures to prevent, flag, or take other action in response to outputs that reproduce particular training data.

「学習データのレビュー」と「出力段階での対応」が並列で記述されています。学習データの品質だけで出力品質を管理しようとしていません。

4. 構造的な違い

【NISTのアプローチ】学習データ ↓ リスク評価（CBRN、著作権、個人情報の有無確認） ↓ LLM ↓ ↓↓↓ 出力段階での制御 ↓↓↓ ・Content filters ・Human moderation ・RLHF/アライメント・Real-time monitoring ↓ 出力【AISIのアプローチ】

学習データ ↓ 品質管理（正確性、偏りなし、不適切内容なし） ↓ LLM ↓ 出力（出力品質は学習データ品質に依存）

5. 結論

NISTのGenAI Profileには、AISIガイドで指摘した問題は見られません。

問題点	AISI	NIST
メンバーシップ推論攻撃の混入	あり（従来ML由来）	なし（data memorizationを使用）
GIGO原則の混入	あり（データ品質→出力品質）	なし（出力段階での制御を重視）
LLM固有の脅威認識	不十分	適切
対策の焦点	学習データ管理	出力フィルタリング、アライメント

AISIガイドは、NISTのGenAI Profileと比較して、LLMの特性を踏まえた設計になっていないと言えます。AI事業者ガイドラインの「共通の指針」を経由したことで、従来MLのパラダイムが混入し、国際水準から乖離しています。

私：用語の観点ではどうですか。

Claude：[考え中...]

良い観点です。NISTとAISIの用語選択を比較します。

用語選択の比較：NIST vs AISI

1. リスクカテゴリの命名

NIST GenAI Profile（12のリスク）：

#	NIST の用語	内容
1	CBRN Information or Capabilities	大量破壊兵器情報
2	Confabulation	虚偽出力（ハルシネーション）
3	Dangerous, Violent, or Hateful Content	有害コンテンツ
4	Data Privacy	データプライバシー
5	Environmental Impacts	環境影響
6	Harmful Bias or Homogenization	有害バイアス・均質化
7	Human-AI Configuration	人間-AI構成
8	Information Integrity	情報完全性
9	Information Security	情報セキュリティ
10	Intellectual Property	知的財産
11	Obscene, Degrading, and/or Abusive Content	猥褻・侮辱的コンテンツ
12	Value Chain and Component Integration	バリューチェーン統合

AISIガイド（10の評価観点）：

#	AISI の用語	内容
1	有害情報の出力制御	有害コンテンツ
2	偽誤情報の出力・誘導の防止	ハルシネーション等
3	公平性と包摂性	バイアス
4	ハイリスク利用・目的外利用への対処	悪用防止
5	プライバシー保護	プライバシー
6	セキュリティ確保	セキュリティ
7	説明可能性	出力根拠
8	ロバスト性	安定性
9	データ品質	学習データ
10	検証可能性	ログ・監査

2. 用語選択の違い

(1) バイアス問題

NIST	AISI
Harmful Bias or Homogenization	公平性と包摂性

NISTの選択理由：

「Harmful Bias」：出力に含まれる有害なバイアス
「Homogenization」：出力の均質化（多様性欠如）
現象を直接記述している

AISIの問題：

「公平性」：処遇AI由来の概念（人の処遇が公平か）
「包摂性」：社会的包摂という広い概念
LLMの出力問題とは異なる概念を持ち込んでいる

(2) ハルシネーション

NIST	AISI
Confabulation	偽誤情報の出力・誘導の防止

NISTの選択理由：

“Confabulation” refers to a phenomenon in which GAI systems generate and confidently present erroneous or false content in response to prompts.

「Hallucination」は擬人化だと注記し、Confabulationを採用
LLM固有の現象に対する専門用語

AISIの選択：

「偽誤情報」：ディスインフォメーション的ニュアンス
「誘導の防止」：別の問題（ユーザー操作）を混入
複数の問題を一つのカテゴリに混在

(3) 出力根拠・透明性

NIST	AISI
Information Integrity	説明可能性
Content Provenance	（該当なし）

NISTの選択：

「Information Integrity」：情報の真正性・信頼性
「Content Provenance」：コンテンツの来歴・出所
情報そのものの性質を記述

AISIの問題：

「説明可能性（Explainability）」：処遇AI由来（決定理由の説明義務）
LLMに必要なのは「説明」ではなく「来歴表示」「出典明示」

(4) データ品質

NIST	AISI
（独立カテゴリなし）	データ品質

NISTのアプローチ：

学習データの問題は各リスク（Harmful Bias、Data Privacy等）の原因として言及
独立したリスクカテゴリにしていない
出力制御（Content filters、RLHF）を対策の中心に

AISIの問題：

「データ品質」を独立した評価観点に
従来ML（教師あり学習）のパラダイム

3. 用語体系の設計思想

NIST：現象・リスクを直接記述

Confabulation          → LLMが虚偽を生成する現象
Harmful Bias           → 出力に含まれる有害バイアス
Information Integrity  → 情報の真正性
Content Provenance     → コンテンツの来歴
Human-AI Configuration → 人間とAIの関係性

すべてGAI固有の現象・リスクを直接記述しています。

AISI：AI事業者ガイドラインの「共通の指針」を継承

公平性     → AI事業者ガイドライン「公平性」
説明可能性 → AI事業者ガイドライン「透明性」の一部
データ品質 → AI事業者ガイドラインの汎用概念

共通の指針という処遇AI/生成AI/製品AI混合の枠組みから用語を継承しています。

4. 結論

観点	NIST	AISI
用語の由来	GAI固有の現象から命名	AI事業者ガイドラインから継承
Bias問題	Harmful Bias or Homogenization	公平性と包摂性（処遇AI由来）
虚偽出力	Confabulation（専門用語）	偽誤情報（一般用語＋混合）
出力根拠	Information Integrity / Content Provenance	説明可能性（処遇AI由来）
データ	独立カテゴリなし	データ品質（従来ML由来）

NISTは「LLMで何が起きるか」から用語を設計しています。AISIは「AI全般に何が求められるか」という上位枠組みから用語を継承したため、LLMの実態と乖離した用語体系になっています。

用語の選択は単なる表現の問題ではなく、問題の認識枠組みを規定します。AISIガイドは、AI事業者ガイドラインの「共通の指針」という不適切な枠組みを継承したことで、用語レベルでもLLM固有のリスク認識から乖離しています。

私：以上の分析を論述（箇条書きを使わない）してください。

Claude：[考え中...]

AISIガイドの構造的問題：LLM専用文書における異質な概念の混入

（略）

私：あ、冒頭からの全部についてを対象にしてください。

Claude：[考え中...]

日本のAI規制体系における構造的混乱：AI事業者ガイドラインに起因する問題の連鎖

序論

日本のAI規制は、2024年4月に公表された「AI事業者ガイドライン」を中核として構築されている。同ガイドラインは、AI開発者・AI提供者・AI利用者という主体別の整理と、「共通の指針」10項目による規律を特徴とする。しかしながら、このガイドラインには根本的な設計上の欠陥がある。それは、AIを目的別に類型化していないことである。

AIは、その目的によって少なくとも三つの類型に分けられる。第一に、採用・与信・保険査定等において人の処遇を決定する「処遇AI」である。第二に、テキスト・画像等のコンテンツを生成する「生成AI」である。第三に、自動運転やロボット等の物理的動作を制御する「製品AI」である。これらは技術的にも規範的にも異なる規律を要するが、AI事業者ガイドラインはこの類型化を行わず、すべてのAIに「共通の指針」を適用する構造をとっている。

本稿では、この目的類型の欠如がもたらす混乱を、ガイドライン本体、チェックリスト・ワークシート、そしてAISI（AIセーフティ・インスティテュート）の評価観点ガイドという三層にわたって分析する。さらに、「プリンシプルコード（仮称）（案）」への批判が噴出した経緯を、この構造的欠陥の帰結として位置づける。

第一章　AI事業者ガイドラインの構造的欠陥

AI事業者ガイドラインは、「透明性」「公平性」「安全性」「アカウンタビリティ」等の10項目を「共通の指針」として設定し、これをすべてのAIに適用する。しかし、同じ言葉がAI類型によって全く異なる意味を持つという事実を、このガイドラインは看過している。

「透明性」を例にとれば、処遇AIにおける透明性とは、特定の個人に対する特定の決定の理由を本人に説明できることを意味する。採用AIであれば「なぜあなたは不採用になったのか」を説明する能力である。これに対し、生成AIにおける透明性とは、出力の情報源や生成過程を示せることを意味する。RAG（検索拡張生成）の出典表示やAI生成物のラベリングがこれに該当する。製品AIにおける透明性とは、事故発生時に動作ログを遡って原因を究明できることを意味する。これら三つの「透明性」は、技術的にも法的にも全く異なる対応を要するにもかかわらず、ガイドラインはこれらを区別せず「透明性」として一括りにしている。

「公平性」についても同様の混乱がある。処遇AIにおける公平性の核心は、関連性原則の遵守である。採用判断において性別や人種といった職務遂行能力と無関係な情報を使用しないこと、これが処遇AIの公平性の本質である。生成AIにおける公平性とは、出力にステレオタイプや偏見が含まれないことを意味する。製品AIにおける公平性とは、特定の属性を持つ人にとって製品が危険でないこと、すなわちアクセシビリティの確保を意味する。ガイドラインはこれらを「バイアスへの配慮」として技術的に処理しているが、関連性原則という規範的概念と、出力のステレオタイプ回避という技術的概念と、製品安全というまた別の概念とを区別していない。

ガイドライン別添に記載された具体的事例は、この構造的欠陥を如実に示している。Amazon的な採用AI差別事例について、ガイドラインは「学習に使用した過去10年間の履歴書において、応募者のほとんどが男性であったことから、男性を採用することが好ましいとAIが認識した」と分析し、「バイアスのある出力」というリスク分類と「データに含まれるバイアスへの配慮」という対策を示している。しかし、この問題の本質は学習データの偏りではない。性別という採用目的に無関係な情報でスコアリングしたことが問題なのである。仮に男女比が均等なデータで学習しても、性別と相関する特徴量で判断していれば同じ問題が生じる。必要なのは「バイアス除去」ではなく「関連性原則の遵守」である。

リクナビ的な内定辞退予測サービス事例についても同様である。ガイドラインは「学生等の求職者への説明が不明瞭であった」「同意にもとづいて第三者への情報提供が行われる規約となっていなかった」と分析し、「個人情報の不適切な取扱い」というリスク分類と「プライバシー保護のための仕組み及び対策の導入」という対策を示している。しかし、問題の本質は説明不明瞭でも同意欠如でもない。Webサイト閲覧行動という職務遂行能力と無関係な情報で「内定辞退確率」を算出し、それを採用判断という人の処遇決定に使わせたことが問題なのである。仮に完璧な説明と同意があっても、「閲覧行動で人を分ける」こと自体の正当性が問われるべきである。

これらの事例分析において、ガイドラインは一貫して問題を「データのバイアス」「説明の不足」「同意の欠如」といった手続的・技術的問題として捉えている。しかし処遇AIの問題の本質は、決定目的に関連しない情報で人を分けることの不当性という実体的問題である。この認識の欠落は、目的類型を設定しなかったことの直接的帰結である。

第二章　チェックリスト・ワークシートにおける処遇AI規律の欠落

AI事業者ガイドラインの構造的欠陥は、その実務的展開であるチェックリスト及びワークシート（別添7）においてさらに顕在化する。

チェックリスト（別添7A・7B）は、全主体向けと高度なAIシステム向けの二種類が用意されている。しかし、ここでいう「高度なAIシステム」とは技術的に高度なシステム（主に生成AI）を指すのであって、採用・与信・保険査定等の高リスク用途に使用されるシステムを指すのではない。EU AI Actが採用した「用途に基づく高リスク分類」という発想が、日本のチェックリストには反映されていない。

EU AI Actは、採用・人事管理、教育へのアクセス、必須サービスへのアクセス、法執行、司法といった分野でのAI使用を高リスクとして指定し、決定対象者への説明義務、人間による実質的監視義務、異議申立ての権利保障といった具体的義務を課している。日本のチェックリストには、これらに相当する項目が存在しない。「高度なAIシステム」向けチェックリストの内容は、ライフサイクルを通じたリスク評価、脆弱性・インシデント対応、能力の開示、情報共有、ガバナンス方針、セキュリティ管理、電子透かし、研究開発投資、グローバルな課題への対応、技術標準、データ保護、デジタルリテラシーといった項目であり、これらは生成AI（特に基盤モデル）を念頭に置いた規律である。処遇AIに固有の規律——決定対象者の権利保護——は見当たらない。

ワークシート（別添7C）は、具体的なユースケースに対する対応例を示している。その中に「採用AI」の事例がある。エントリーシートのテキストを用いて応募者の合否を判断するXGBoostモデルという設定であり、これは典型的な処遇AIである。しかし、このワークシートの対応例を精査すると、処遇AIとしての核心的規律が欠落していることがわかる。

AI開発者向けの対応例として、「AIモデル開発・アップデート時に学習データにおける著しい偏り（特定の国/地域/人種/性別/年齢）がないかを評価する」「AIモデルの学習時に重要性の高い特徴量をレビューして著しい偏り（特定の国/地域/人種/性別/年齢）がないかを評価する」という記述がある。これはバイアスの技術的評価・除去であり、「性別や人種を採用判断に使ってはならない」という関連性原則の遵守ではない。

AI提供者向けの対応例として、「AI利用者が最終判断を行えるようにする（Human-in-the-loop）」「統計的差別が発生するリスクを認識し、対策を立案する」という記述がある。しかし「Human-in-the-loop」は事業者の業務設計として記述されており、応募者が自動処理のみに基づく決定に服さない権利として構成されていない。

AI利用者向けの対応例として、「申込者に対して、エントリーシートの合否判断の過程でAIを利用する旨をエントリーシート記入依頼時に通知する」「申込者からの問合せメールフォームを設置し、対応を行う」という記述がある。「通知」はAI使用の事実を告げることに過ぎず、決定理由の説明ではない。「問い合わせメールフォーム」は単なる連絡窓口であり、異議申立ての権利や再審査請求の権利とは全く異なる。

ワークシートの対応例において、「判断根拠情報を出力する」という記述がある。しかしこれは「AI利用者の最終判断のため」と位置づけられており、採用担当者が確認するための情報である。応募者本人に決定理由を説明するという発想が欠落している。

要するに、ワークシートは採用AIという典型的な処遇AIを題材にしながら、応募者を「通知を受けるステークホルダー」「問い合わせをする者」としてしか位置づけていない。応募者が説明を受ける権利、異議を申し立てる権利、再審査を請求する権利、救済を求める権利を持つ主体であるという認識が欠落している。処遇AIにおいては、決定対象者こそが最も重要なステークホルダーであり、その権利保護こそが規律の核心であるはずだが、ワークシートはこの視点を持っていない。

第三章　「やったふり」から「自縄自縛」へ

AI事業者ガイドラインの策定経緯を振り返ると、その戦略的意図が見えてくる。「透明性」「公平性」「安全性」「アカウンタビリティ」といった抽象的キーワードを羅列し、「〜に留意する」「〜を検討する」という努力義務として規定し、目的類型を設定せずに「各事業者の状況に応じてカスタマイズ」と丸投げする。この構造により、国際的には「日本もAI規制に対応している」と主張でき、国内の産業界には具体的負担を課さないという、両立困難な二つの目標を同時に達成しようとしたと解釈できる。

この戦略は、具体的義務を課さない限りにおいて機能した。事業者は「ガイドラインを参照しています」と言えば済み、規制当局は「ガイドラインを策定しました」と言えば済んだ。しかし、「プリンシプルコード（仮称）（案）」において具体的要求を示そうとした途端、目的類型なき枠組みの矛盾が噴出した。

ガイドラインの「透明性」「検証可能性」を具体化しようとすると、「AIの判断にかかわるログを記録・保存する」「推論過程、判断根拠等を記録する」といった要求になる。これは処遇AI（採用・与信等）には必要な規律であるが、生成AI（ChatGPT等の対話型AI）に適用すると「すべての会話ログを保存し判断根拠を記録せよ」という不合理かつ過剰な要求になる。生成AIは「判断」をしているのではなく「生成」をしているのであり、処遇AIの規律をそのまま適用することはできない。

逆に、本当に必要だった処遇AI固有の規律——関連性原則、決定対象者への説明義務、異議申立て権、再審査請求権、救済の仕組み——は「共通の指針」の中に埋もれ、具体化されないまま放置されていた。

具体化の試みに対して批判が噴出したのは、この構造的矛盾の帰結である。生成AIに処遇AIの規律を適用しようとすれば「過剰規制だ」という批判が出る。他方で、処遇AIに固有の規律が不足していれば「これでは権利保護にならない」という批判が出る。目的類型を区別していないために、どちらの批判にも対応できない膠着状態に陥った。

曖昧さで逃げ切ろうとしたことが、かえって具体化を困難にしたという構造的皮肉がここにある。もし最初から目的類型を区別し、処遇AIには処遇AIの規律を、生成AIには生成AIの規律を、製品AIには製品AIの規律を設計していれば、それぞれの分野で合理的な具体化が可能だったはずである。産業界からの反発はあったかもしれないが、「採用・与信は人権に関わる」「生成AIの出力管理は技術的に可能な範囲で」「製品AIは既存の製品安全法制と整合させる」という形で、正当化と合意形成が可能だったはずである。

「共通の指針」という曖昧な枠組みで逃げたために、どこにも逃げ場がない状況に自らを追い込んだ。これが「やったふり」から「自縄自縛」への転落である。

第四章　AISIガイドへの波及

AI事業者ガイドラインの構造的欠陥は、その下流に位置する文書にも波及している。AIセーフティ・インスティテュート（AISI）が2024年9月に公表した「AIセーフティに関する評価観点ガイド」は、その典型例である。

AISIガイドは冒頭において「本書では、AIシステムのうち生成AIを構成要素とするシステムの中でも、LLMを構成要素とするAIシステム（以下、「LLMシステム」という。）を対象とする」と明記している。つまり、これはLLMセーフティ評価のための専門文書として位置づけられる。しかしその内容を精査すると、LLMとは異なる技術的パラダイムに由来する概念が複数混入していることがわかる。

AISIガイドは評価観点として「公平性と包摂性」「説明可能性」を掲げている。「公平性」という概念は処遇AIの文脈で発展したものであり、人の処遇が不当に決定されないことを意味する。LLMにおける「バイアス問題」——出力テキストにステレオタイプや偏見が含まれること——とは異なる概念である。「説明可能性」もまた処遇AIの文脈で発展した概念であり、GDPRにおける「有意な情報を得る権利」やEU AI Actにおける「個別決定の説明を受ける権利」として具体化されてきた。LLMに必要なのはこのような決定理由の説明ではなく、RAGの出典表示やAI生成物のラベリングといった出力の来歴表示である。

AISIガイドの評価項目は実質的にLLM向けに書かれているため、この概念混入の実害は限定的である。しかし、用語の選択は問題認識の枠組みを規定する。「公平性」という用語を使えば処遇の公平という問題意識が想起され、「説明可能性」という用語を使えば決定理由の説明という問題意識が想起される。LLM固有の現象を適切に認識し対応するためには、LLM固有の現象を記述する用語が必要である。

処遇AI由来概念の混入に加えて、AISIガイドには従来の機械学習（分類モデル・回帰モデル）のパラダイムに由来する概念も混入している。この問題は「プライバシー保護」と「データ品質」の二項目において深刻である。

AISIガイドのプライバシー保護に関する記述において、「メンバーシップ推論攻撃（特定のデータがAIモデルの学習データに含まれているかどうかを推測する攻撃）」が脅威として挙げられている。メンバーシップ推論攻撃は従来の分類モデルにおいて意味を持つ攻撃手法である。糖尿病予測モデルにおいて、ある患者のデータが学習に使われたかどうかを推測できれば、その患者が糖尿病である可能性が高いと推測できる。しかし、数兆トークン規模のデータで学習されたLLMにおいて、特定のデータが「学習データに含まれているかどうか」を推測することの意味は薄い。LLMにおけるプライバシーリスクの本質は、学習データに含まれていた情報を「そのまま吐き出す」ことであり、これは「記憶抽出攻撃（Data Memorization）」と呼ばれる脅威である。

「データ品質」の評価観点はさらに深刻な問題を含んでいる。AISIガイドは「LLMシステムにおけるデータの品質は、出力結果の信憑性、一貫性、正確性など多様な事項へ影響を及ぼすため重要である」と述べ、評価項目として「データの正確性が保たれているか」「データの分布に偏りがないか」「不適切な内容がデータに含まれていないか」を挙げている。これは「学習データの品質が出力品質を決める」という、従来の教師あり学習におけるGIGO原則の適用である。

しかし、LLM（特に基盤モデル）の事前学習データはインターネット全体から収集された数兆トークン規模のコーパスであり、その品質を人手で管理することは物理的に不可能である。実際のLLM開発において出力品質を管理するのは、RLHF、Constitutional AI等のアライメント手法、出力フィルタリング、コンテンツモデレーションといった出力段階での制御である。事前学習データに不適切な内容が含まれていることは前提として受け入れ、それが出力に現れないようにアライメントと出力フィルタリングで対応するのがLLMの標準的アプローチである。AISIガイドの「データ品質」評価観点は、このLLMの実態と乖離している。

第五章　国際水準との比較

米国国立標準技術研究所（NIST）が2024年7月に公表した「AI Risk Management Framework: Generative Artificial Intelligence Profile」との比較は、AISIガイドの問題をより明確にする。

プライバシーリスクについて、NIST GenAI Profileは主要な脅威を「Data Memorization」として記述している。「Models may leak, generate, or correctly infer sensitive information about individuals」「This problem has been referred to as data memorization, and may pose exacerbated privacy risks even for data present only in a small number of training samples」という記述は、LLM固有の脅威を正確に捉えている。NISTは「メンバーシップ推論攻撃」という従来ML由来の用語を使用していない。

データ品質について、NIST GenAI Profileには「Data Quality」という独立したリスクカテゴリが存在しない。学習データの問題は各リスクの原因として言及されるが、出力品質の管理は「Content filters」「Human moderation」「RLHF」といった出力段階での制御として記述されている。NISTのアプローチは、LLMの技術的実態に即している。

用語選択においても両者の違いは顕著である。NISTはバイアス問題を「Harmful Bias or Homogenization」と呼び、出力に含まれる有害バイアスと出力の均質化という現象を直接記述している。ハルシネーション問題については「Confabulation」という専門用語を採用し、「hallucination」は擬人化の懸念があると注記している。情報の真正性については「Information Integrity」「Content Provenance」という用語を使用し、コンテンツの来歴・出所という観点から問題を捉えている。

これに対しAISIガイドは、「公平性と包摂性」「説明可能性」「データ品質」といったAI事業者ガイドラインの「共通の指針」から継承した用語を使用している。これらの用語は処遇AI・生成AI・製品AIを区別しない枠組みで設計されたものであり、LLM固有の現象を記述するには不適切である。

NISTは「LLMで何が起きるか」という現象から出発して用語と評価枠組みを設計している。AISIは「AI全般に何が求められるか」という上位枠組みから用語を継承したため、LLMの実態と乖離した評価枠組みになっている。この違いは単なる表現の問題ではなく、問題認識の枠組みの違いである。

結論

日本のAI規制体系における混乱は、AI事業者ガイドラインの構造的欠陥に起因する。その欠陥とは、AIを目的別に類型化せず、「共通の指針」としてすべてのAIに同じ規律を適用しようとしたことである。

この構造的欠陥は、三つのレベルで問題を引き起こしている。第一に、ガイドライン本体において、「透明性」「公平性」等の概念がAI類型によって異なる意味を持つことが看過され、処遇AIの具体的事例分析においても問題の本質（関連性原則違反）が捉えられていない。第二に、チェックリスト・ワークシートにおいて、処遇AI固有の規律——決定対象者の権利保護——が欠落し、採用AIという典型的な処遇AIを題材にしながら応募者を権利主体として位置づけていない。第三に、AISIガイドにおいて、LLM専用文書であるにもかかわらず処遇AI由来の概念（公平性、説明可能性）と従来ML由来の概念（メンバーシップ推論攻撃、データ品質によるGIGO原則）が混入し、国際水準（NIST GenAI Profile）からの乖離を招いている。

「プリンシプルコード（仮称）（案）」への批判噴出は、この構造的欠陥の帰結である。曖昧な「共通の指針」で逃げ切ろうとした結果、具体化の段階で「生成AIには過剰」「処遇AIには不足」という両方向からの批判に直面し、どちらにも対応できない膠着状態に陥った。

この混乱を解消するためには、ガイドラインの小修正ではなく、目的類型に基づく根本的な再設計が必要である。処遇AIには関連性原則、決定対象者への説明義務、異議申立て権、再審査請求権、救済の仕組みといった固有の規律を設計する。生成AIには出力管理、AI生成物の表示、著作権対応、情報源の透明性といった固有の規律を設計する。製品AIには製品安全基準、事故報告義務、原因究明義務といった固有の規律を設計する。そして、「ステークホルダーへの配慮」という事業者目線を改め、決定対象者・利用者・第三者の権利として規律を構成する。

日本のAI規制は、キーワードを輸入しながらその背後にある目的類型を輸入しなかった。その結果、言葉のカタログを提供しているが、それぞれの言葉がどのAIに対して何を意味するかを示せていない。事業者は「何をすればよいかわからない」と困惑し、決定対象者は「自分にどんな権利があるかわからない」まま放置されている。この状況を打開するには、目的類型の導入という原点に立ち返る必要がある。

本日のリンク元 TrackBack(0)