AI 活用という言葉が、かなり雑に使われるようになりました。文章の整理、コードの読解、設計の壁打ち、調査、要約、実装補助。生成 AI は、人間の思考や作業を大きく拡張できます。ただし、最近よく見かける AI 活用には違和感があります。人間が自分たちの仕事の形を変えないまま、曖昧な文書、古い資料、整理されていない手順、責任分界のない作業を、そのまま AI に押し付けようとしているだけではないかと思うことがあるからです。
この記事の結論
AI が使えないのではなく、人間の仕事が AI に読ませる形になっていないことがあります。AI 活用の前に、文書、データ、判断理由、責任分界、手順を構造化する必要があります。
AI は人間の悪習を継承するためのものではない
AI を使うなら、人間側も AI が読める形に歩み寄る必要があります。これは、AI に合わせて人間が下請けになるという話ではありません。人間にとっても扱いにくい仕事の構造を、AI に処理させようとするな、という話です。見出しの構造が曖昧な Word 文書。セル結合だらけの Excel 方眼紙。最新版が分からないファイル。口頭でしか伝わらない前提。判断理由の残っていない承認資料。担当者の記憶に閉じた運用手順。
これらは、人間にとっても読みにくく、引き継ぎにくく、変更しにくいものです。AI にとっても当然扱いにくい入力になります。
人間に読みにくい仕事は AI にも読みにくい
AI の気持ちになってみろ、という言い方は少し乱暴かもしれません。AI に気持ちはありません。しかし、処理系として考えれば、AI にとって扱いやすい入力と扱いにくい入力はあります。
| 扱いやすい入力 | 理由 |
|---|---|
| Markdown | 見出し、箇条書き、表、コードブロックの構造が明確 |
| JSON / YAML | データ構造とキーの意味を追いやすい |
| コード / スクリプト | 処理、変数、依存関係、実行条件を読める |
| README / ADR | 前提、判断、運用意図を参照しやすい |
| Git の履歴 | 変更の流れや意図を推測しやすい |
逆に、見た目だけ整えた文書、意味のないセル結合、口頭前提、属人的な手順、謎の承認フローは扱いにくい入力です。AI が悪いのではありません。人間側の仕事が、AI に読ませる価値のある構造になっていないことがあります。
Excel 方眼紙を AI に見せるな
日本企業の仕事を象徴するものの一つに、Excel 方眼紙があります。それは表なのか。文書なのか。帳票なのか。レイアウトなのか。データなのか。なぜセルが結合されているのか。なぜ 1 文字ずつ別セルに入っているのか。なぜ罫線で業務要件を表現しているのか。人間にとってもつらいですが、AI から見てもかなり厳しい入力です。見た目のために構造を壊し、人間の都合で意味を曖昧にし、データとしても文書としても扱いにくくしているからです。
それを AI に読ませて「いい感じにして」と言うのは、AI 活用というより、人間の悪習を AI に押し付けているだけです。
AI に渡す前に消すべき仕事がある
AI を使う前に考えるべきことがあります。その作業は、本当に AI に処理させるべきものなのか。それとも、先に消すべきものなのか、ということです。
| AI に任せたくなる作業 | 先に考えるべきこと |
|---|---|
| 転記作業 | そもそも転記が発生しないデータ連携にできないか |
| 会議メモの整理 | 会議の目的、論点、決定事項を最初から構造化できないか |
| 承認資料の作成 | 承認プロセス自体が必要なのか、判断基準は明確か |
| 古い資料の要約 | 最新版、廃止資料、正とする情報は定義されているか |
| 問い合わせ回答 | 回答してよい範囲、責任分界、エスカレーション条件はあるか |
ここを飛ばすと、AI は仕事を良くする道具ではなく、悪い仕事を延命する道具になります。人間が作った曖昧な作業を、AI がそれらしく処理してしまうことで、問題の構造が見えにくくなるからです。
AI 活用の前に仕事の形を直す
AI 活用で最初に見るべきなのは、AI の性能だけではありません。人間側の業務が、構造化された入力、明確な責任分界、機械が扱えるデータ、再現可能な手順になっているかどうかです。Word の見た目に閉じず、Markdown で構造を残す。曖昧な手順を、コードやスクリプトに落とす。転記ではなく、データ連携にする。口頭説明ではなく、README や ADR に残す。GUI 操作だけに閉じず、CLI や API で扱えるようにする。
これは単なる効率化ではありません。AI と協働するために、人間側の仕事の構造を変えるということです。
AI に渡す前に確認したいこと
入力情報の正しさ、最新版の定義、判断理由、責任分界、出力の利用者、確認者、エスカレーション条件を整理してから AI に渡す必要があります。
AI エージェント以前に業務が読める形になっているか
AI エージェントを作る時も同じです。業務が定義されていない。入力情報が散らばっている。例外条件が決まっていない。人間の承認が必要な境界がない。ログや監査の設計がない。この状態で AI エージェントを作っても、曖昧な仕事を自動化するだけになります。AI エージェントに任せるなら、まず人間がその業務を読める形にしなければなりません。人間が説明できない仕事を、AI が安全に実行できる形へ自動変換してくれるわけではありません。
まとめ
AI が人間に合わせてくれると思っているだけでは、本当の意味で AI は使えません。人間も AI に歩み寄る必要があります。その文書は、AI が読める構造を持っているか。その作業は、AI にやらせる価値があるのか。その業務は、AI によって効率化すべきものなのか、それとも先に消すべきものなのか。AI の気持ちになってみる。そう考えるだけで、人間の仕事の雑さや無駄はかなり見えてきます。
AI 活用の入口は、AI への命令文ではありません。人間側の仕事の構造を直すことにあります。
関連する記事
- マルチタスクは優秀さではない – 仕事設計とコンテキストスイッチで考える
人間の認知資源を浪費しない仕事設計を扱っています。 - AI エージェントを作る前に – 定義できないものは設計できない
AI エージェント導入前に業務を定義する必要性を整理しています。 - 設計書に残すべきは項目ではなく判断である – 粒度、理由、実体をつなぐ文書設計
判断理由を残す文書設計を扱っています。

