AIと一緒に記事を書く: 指示の設計と評価

記事を書く作業をAIに任せたいと思ったとき、最初にやるのは「指示を書く」ことです。どんな記事を書いてほしいか、どんな構成にするか、どんな文体で書くか。指示を書いて、AIに渡して、出てきた記事を見て、また指示を直す。この繰り返しをしているうちに、あることに気づきます。

指示を直すたびに、自分が何を求めているのかが明確になっていく。AIの出力を見て「これは違う」と感じるとき、何が違うのかを言語化しなければならない。その言語化が、指示を改善するだけでなく、自分の中に隠れていた基準を浮かび上がらせる。

この記事では、記事執筆をAIに委譲していく過程で見えてきた「改善サイクル」について整理します。成果物から指示を評価し、指示から成果物を評価し、その両方を俯瞰して仕組み自体を評価する。このメタ構造が、AIとの協働で本質的に価値のある部分だと考えています。

要点

AIに仕事を任せるとき、価値があるのは「良い指示を書くこと」ではなく「指示を改善し続ける仕組みを作ること」です。

具体的な作業から始め、少しずつAIに委譲し、出てきた成果物を見て指示を直す。このサイクルを回すうちに、指示自体を評価する基準が必要になります。さらに進むと、その評価基準自体が適切かを問うことになります。成果物→指示→評価基準→評価基準の評価、というメタのメタへと視点が上がっていく。

ここまで来ると、AIは単なる執筆代行ではなく、自分の考えを外に出して確かめる相手になります。

具体から始める

最初は、自分で記事を書きます。AIに頼らず、手を動かして書く。この段階で重要なのは、自分がどう考えて書いているかを観察することです。

どこで迷うか。何を調べるか。どの順番で書くか。どこを削るか。こうした判断の一つ一つが、後でAIに伝えるべき「指示」の素材になります。自分で書かずにいきなり指示を書こうとすると、暗黙に持っている基準が言語化されないまま残ります。

記事を書きながら、同時に「この判断をどう言葉にするか」を考えます。たとえば「導入は短くする」という判断をしたとき、なぜ短くしたのか。「読者が早く本題に入りたいから」なのか、「前置きが長いと離脱するから」なのか。理由を掘り下げると、より本質的な原則が見えてきます。

少しずつ委譲する

次に、作業の一部をAIに任せてみます。いきなり全部を任せるのではなく、一部だけ。たとえば「このセクションの下書きを書いて」とか「この箇条書きを段落に直して」とか。

AIの出力を見て、期待と違う部分を見つけます。違うと感じたら、何が違うのかを言語化します。「もっと具体的に」では不十分です。「読者が自分の状況に当てはめられるレベルの具体」のように、何を基準に「具体的」と判断するかを明示します。

この言語化を繰り返すと、指示が少しずつ具体的になっていきます。最初は「良い記事を書いて」だったものが、「読者が早く判断できる」「核心が先に来る」「理由と限界がセットになる」といった原則に分解されていきます。

指示を評価させる

ある程度指示がまとまったら、次のステップに進みます。AIに「この指示を評価して」と頼むのです。

これは奇妙に聞こえるかもしれません。指示を書いた本人がAIに評価させるなんて、意味があるのか。しかし、やってみると驚くほど有用です。AIは指示を客観的に読み、構造的な問題（重複、矛盾、曖昧さ）を指摘できます。自分では気づかなかった「暗黙の前提」が、AIの目には「欠けている情報」として映ります。

この段階で、評価の基準が必要になります。何を基準に「良い指示」と判断するのか。私たちは3層のフレームワークを使いました。

• 構造層（読めるか）: 分量、順序、重複、粒度
• 意味層（わかるか）: 明確性、具体性、一貫性、完全性
• 機能層（使えるか）: 再現性、適用可能性、柔軟性、検証可能性

構造と意味が良くても、実際に使って期待通りの成果物が出なければ意味がありません。逆に、機能層で問題が出たとき、構造層・意味層のどこに原因があるかを追えることが重要です。

成果物から仕組みを再評価する

さらに進むと、評価基準自体を問うことになります。

指示を改善し、AIに記事を書かせ、その記事を見たときに「指示通りだけど、何か違う」と感じることがあります。指示は守られている。評価基準も満たしている。でも、良い記事になっていない。

このとき問うべきは「指示が悪い」ではなく「評価基準が悪い」です。何を測っていたのか。本当に測るべきものを測っていたのか。評価基準自体を成果物に照らして検証する必要があります。

たとえば、最初は「記事の型」を固定していました。導入→要点→背景→本質→実践→注意点→まとめ、という順番です。この型に従えば「良い記事」になるはずでした。しかし、事例紹介やアイデア記事を書こうとすると、型に合わせようとして不自然になりました。

型を評価基準にしていたことが問題でした。型の背後にある本質（読者が早く判断できる、核心が先に来る、など）を抽出し、それを評価基準にすることで、様々な種類の記事に適用できるようになりました。

メタのメタへ

この「評価基準を評価する」という視点は、さらに上に続きます。

評価基準を評価するための基準は何か。それを評価するための基準は何か。無限後退に陥りそうですが、実際には「成果物の品質」という現実がストッパーになります。どれだけ美しいフレームワークを作っても、出てくる記事が良くなければ意味がない。最終的には成果物に戻ってくる。

このサイクルを図にすると、こうなります。

成果物から指示を評価し、指示を改善して成果物を作る。同時に、成果物から評価基準自体を評価し、必要なら評価基準を改善する。この二重のループが回ることで、指示も評価基準も継続的に改善されていきます。

何が起きているのか

この改善サイクルで起きていることは、単なる「AIへの業務委譲」ではありません。

自分の中にあった暗黙の基準が、言語化されて外に出る。外に出た基準がAIによって検証される。検証結果を見て、基準自体を問い直す。この過程で、自分が「良い記事」と呼んでいたものの本質が明確になっていきます。

AIは鏡のような役割を果たします。自分の思考を映し出し、曖昧な部分を浮き彫りにする。「なんとなく良い」では通じないので、「何が良いのか」を言語化せざるを得ない。その言語化が、自分の思考を深める。

これは記事執筆に限った話ではありません。AIに何かを任せようとするとき、同じ構造が現れます。具体的な作業から始め、少しずつ委譲し、成果物から指示を評価し、評価基準自体を問い直す。このサイクルを回せるかどうかが、AIとの協働の質を決めます。

注意点

このアプローチには限界があります。

すべてを言語化できるわけではない。 複雑な判断や文脈依存の高い判断は、指示だけでは伝わりません。そういった部分は、例示を増やすか、人間がレビューする前提で設計します。

改善サイクルにはコストがかかる。 指示を書き、評価し、改善し、また成果物を作る。この繰り返しは時間がかかります。一度だけ使う指示なら、このコストは回収できません。繰り返し使う指示だからこそ、改善に投資する価値があります。

「良い成果物」の定義は外部にある。 評価基準をどれだけ洗練させても、「良い記事とは何か」の最終判断は読者が下します。自己完結した改善サイクルに陥らないよう、外部からのフィードバックを取り入れる必要があります。

まとめ

AIに記事を書かせる過程で見えてきたのは、「良い指示を書く」ことより「指示を改善し続ける仕組みを作る」ことの重要性でした。

具体的な作業から始め、少しずつAIに委譲し、成果物を見て指示を直す。指示自体を評価させ、評価基準を明示する。成果物が期待と違うとき、指示だけでなく評価基準自体を問い直す。このメタのメタへと視点が上がっていく過程が、AIとの協働で本質的に価値のある部分です。

最初から完璧な指示を書こうとするより、改善サイクルを回せる状態で始める方が現実的です。そのサイクルの中で、自分が何を求めているのかが明確になっていきます。

（ちなみにこの記事自体、まさにそのサイクルの中で生まれました。記事の指示を評価し、評価基準を作り、その評価基準を記事にして、その記事をまた評価して……。考えすぎると頭が痛くなりますね。）

付録: 指示ドキュメントの評価方法

本文中で触れた「評価基準」の具体例として、以下に全文を付録として掲載します。

# 指示ドキュメントの評価方法

指示ドキュメント（方針、ガイドライン、ルール集など）を評価するためのフレームワーク。

## 評価の目的

指示ドキュメントは「読み手（人間またはAI）が意図通りの成果物を生成できるようにする」ために存在する。評価の目的は、その指示が目的を達成できるかを検証することにある。

## 評価の3層構造

指示ドキュメントの品質は、以下の3層で評価する。

### 1. 構造層（読めるか）

指示が物理的・認知的に読みやすいか。

| 観点 | 良い状態 | 悪い状態 |
|------|----------|----------|
| 分量 | 必要十分。1画面で概要が把握できる | 長すぎて全体像が見えない、または短すぎて情報が足りない |
| 順序 | 抽象→具体、または依存関係順に並ぶ | 関連する項目が散らばっている |
| 粒度 | 各セクションの詳細度が揃っている | 一部だけ詳細、他は曖昧 |
| 重複 | 同じ内容が複数箇所にない | 同じルールが別の言葉で繰り返される |
| 参照性 | 必要な情報にすぐたどり着ける | 探さないと見つからない |

**評価方法:**
- 目次だけで全体構造が把握できるか
- 任意の項目を探すのに何秒かかるか
- 同じ内容を説明している箇所が複数ないか

### 2. 意味層（わかるか）

指示の意図が正しく伝わるか。

| 観点 | 良い状態 | 悪い状態 |
|------|----------|----------|
| 明確性 | 解釈が一意に定まる | 読み手によって解釈が分かれる |
| 具体性 | 行動に移せるレベルで書かれている | 抽象的で何をすればいいかわからない |
| 一貫性 | 指示同士が矛盾しない | AとBで言っていることが違う |
| 完全性 | 必要な情報が揃っている | 判断に必要な情報が欠けている |
| 例示 | 具体例があり理解を助ける | 抽象的な説明のみ |

**評価方法:**
- 指示を読んだ後、具体的な行動を3つ挙げられるか
- 2人の読み手が同じ解釈をするか
- 「〜の場合はどうするか」に答えられるか

### 3. 機能層（使えるか）

指示が実際に目的を達成できるか。

| 観点 | 良い状態 | 悪い状態 |
|------|----------|----------|
| 再現性 | 誰が読んでも同じ品質の成果物が出る | 読み手によって成果物の品質が大きく異なる |
| 適用可能性 | 想定するケースをカバーしている | 例外ケースで破綻する |
| 柔軟性 | 様々なパターンに適用できる | 特定のパターンにしか使えない |
| 検証可能性 | 成果物が指示を満たしているか判定できる | 満たしているかどうか曖昧 |
| 改善可能性 | 問題があったとき修正箇所が特定できる | どこを直せばいいかわからない |

**評価方法:**
- 指示に従って成果物を作り、品質を検証する
- 異なる種類のケースで適用してみる
- 成果物の問題点から指示の改善点を逆算できるか

## 評価プロセス

### Step 1: 目的の確認

指示ドキュメントが何を達成しようとしているかを明確にする。

- 誰が読むか（人間、AI、両方）
- 何を生成するか（コード、文章、判断など）
- どんな品質を期待するか

### Step 2: 構造層の評価

ドキュメントを俯瞰し、構造的な問題を洗い出す。

```
チェック項目:
□ 全体の分量は適切か
□ セクションの順序は論理的か
□ 重複している内容はないか
□ 粒度は揃っているか
□ 必要な情報にすぐアクセスできるか
```

### Step 3: 意味層の評価

各セクションを読み、意味的な問題を洗い出す。

```
チェック項目:
□ 解釈が一意に定まるか
□ 具体的な行動に移せるか
□ 指示同士に矛盾はないか
□ 判断に必要な情報は揃っているか
□ 具体例は十分か
```

### Step 4: 機能層の評価

実際に指示を使って成果物を作り、機能的な問題を洗い出す。

```
チェック項目:
□ 指示通りに作った成果物は期待品質を満たすか
□ 異なるケースでも適用できるか
□ 成果物が指示を満たしているか判定できるか
□ 問題があったとき修正箇所を特定できるか
```

### Step 5: 改善の優先順位付け

発見した問題を以下の基準で優先順位付けする。

| 優先度 | 基準 |
|--------|------|
| 高 | 成果物の品質に直接影響する |
| 中 | 読み手の効率に影響する |
| 低 | あると便利だが必須ではない |

## 評価の観点（AIエージェント向け）

AIエージェントが指示を読む場合、人間とは異なる観点が必要になる。

### AIエージェント固有の観点

| 観点 | 説明 |
|------|------|
| トークン効率 | 必要な情報が少ないトークンで伝わるか |
| 参照の明確性 | 「上記」「前述」などの曖昧な参照がないか |
| 条件の網羅性 | 判断分岐の条件が明示されているか |
| 出力形式の明確性 | 期待する出力の形式が具体的か |
| エラーハンドリング | 判断できない場合の対処が書かれているか |

### AIエージェント向けチェックリスト

```
□ 曖昧な指示語（これ、それ、上記など）を使っていないか
□ 暗黙の前提を明示しているか
□ 判断基準が定量的または具体的か
□ 例外ケースの扱いが書かれているか
□ 優先順位が明確か（矛盾する指示があった場合どちらを優先するか）
```

## 評価結果の記録

評価結果は以下の形式で記録する。

```markdown
## 評価対象
- ドキュメント名:
- 評価日:
- 評価者:

## 評価結果サマリ
| 層 | 評価 | 主な問題点 |
|----|------|------------|
| 構造層 | ○/△/× | |
| 意味層 | ○/△/× | |
| 機能層 | ○/△/× | |

## 詳細

### 構造層
- 良い点:
- 問題点:
- 改善案:

### 意味層
- 良い点:
- 問題点:
- 改善案:

### 機能層
- 良い点:
- 問題点:
- 改善案:

## 改善の優先順位
1. （高）
2. （中）
3. （低）
```

## メタ評価：この評価方法自体の評価

評価方法自体も以下の観点で定期的に見直す。

| 観点 | 問い |
|------|------|
| 有用性 | この評価方法で問題が発見できているか |
| 効率性 | 評価にかかる時間は妥当か |
| 網羅性 | 見落としている観点はないか |
| 適用性 | 様々な種類の指示ドキュメントに使えるか |

評価方法自体に問題があれば、このドキュメントを改善する。