誰がAXをできるのか。業務をコードに落とし込める人の条件
誰がAXをできるのか。業務をコードに落とし込める人の条件
2026年7月14日に閣議決定された第Ⅱ期AI基本計画は、意思決定や業務の進め方をAI前提で見直す「AX」を、政府、企業、地方のすべてに求めた。ただし計画は「誰がやるか」までは書いていない。この記事は、計画を図解で読んだ記事の末尾に私見として書いた「誰がAXをできるのか」を独立させ、Claude Code の作者 Boris Cherny のポストとつなげて考えを足したものだ。
先に要点を3つ。
- AXができるのは、どこを変えるべきかを見抜くドメイン知識と、結果に責任を持てるプログラミング知識の両方を持つ人だと考えている
- Boris Cherny は「一流のエンジニアは常に自分の仕事を自動化し、ドメイン知識をインフラとして刻んできた。エージェント時代の作法はその自然な延長にある」と書いた。AXの実体は、このエンジニアの伝統をAIでドメイン知識ごと広げることだ
- 具体的には、業務を決定論的な処理と非決定論的な処理に分け、前者をコードに落とす。この切り分けの勘どころはプログラミング知識がないとつかみにくいので、過渡期の今は、プログラミングを使える人がAXの担い手になっていく
AXができる人の条件は2軸で整理できる
業務フローをAI前提で書き換えるには、どこを変えるべきかを見抜くドメイン知識と、AIとソフトウェアをどう組み合わせるかを判断して結果に責任を持てるプログラミング知識の、両方が要ると考えている。図1がその整理だ。
ドメイン知識だけの人が単独でAXに踏み込めない理由は、実装できないことよりも、AIの出力を検証して何かあったときに責任を取る判断ができないことにある。この場合は、プログラミング知識があって保守までできる人とペアを組めばよい。逆にプログラミング知識だけの人は、ツールは作れても業務のどこを書き換えると価値が出るのかが分からない。
もう1つ、両方を持つ人が組織の中でAXをやろうとすると、既存の業務フローを否定する側に回るので摩擦が大きい。だから現実には、独立や業務委託という形で外部から入る方が動きやすい。勘のいい人はこの構造にすでに気づいていて、独立してこの立ち位置を取っている、というのが私の観測だ。
Boris Cherny のポスト。一流のエンジニアは常に自動化してきた
この整理と同じ週に、Claude Code の作者 Boris Cherny が、同じ構図をエンジニアの側から説明するポストを書いた。
昔から最高のエンジニアたちは、自分の仕事の自動化に多くの時間を使ってきた。エディタ操作の自動化、同じ種類のコードの問題を機械的に捕まえる lint ルール、手動の動作確認を不要にする E2E テスト群。自分の出力を何倍にもするから、エンジニアにとって最も割のいい時間の使い方だった。ポストは、この伝統がエージェント時代にさらに重要になる理由を3つ挙げている。
- 自動化はエージェント全員を速くする。 開発環境や作業手順の自動化は、自分を速くするだけでなく、走らせているエージェントの一つひとつを速くする
- 処理をコードに移すと、その種類の問題は恒久的に片付く。 エージェントは同じ問題を見つけるたびに直せるが、毎回トークンを消費し、取りこぼしも出る。lint ルールや CI の1ステップに落とせば、以後ずっと自動で処理される
- 自動化は参入の壁を下げる。 新しく来た人の邪魔をするのは、人の頭の中にだけあるドメイン知識だ。それが今は lint ルールや型やテストに限らず、コードコメント、スキル、CLAUDE.md のルール、メモリとして、ほぼすべてコードベース側に書き込めるようになった
そのうえで、すべてのチームは、プロンプトに追加の説明を書かなくてもエージェントが生産的に働ける CLAUDE.md やスキルやドキュメントを書くべきだと続け、こう締めている。これは突飛な話ではなく、エンジニアが常にやってきたこと、つまり自動化し、ドメイン知識をインフラとして刻み込むという行為の自然な延長線上にある、と。
決定論的な処理と、非決定論的な処理を分ける
このポストに同意するのは、AXの実作業がまさにこの通りだからだ。業務をAI前提で組み直すときに最初にやるべきなのは、決定論的な処理と、非決定論的な非構造化データの処理を分けて考えることだと思っている。入力が決まれば出力が決まる、ルールに書き切れる処理はコードに落とす。文書の解釈や例外への対応のような、揺らぎを扱う処理だけをAIに残す。ポイントは、業務のどれだけをコードに落とせるかにある。
Boris の2つ目の理由はこの話そのものだ。コードに落とさずエージェントに任せ続けると、同じ判断に毎回トークンを払い、取りこぼしのリスクも毎回引き受けることになる。
進め方はこうなる。あらゆる事象をまず言語にしてAIに伝え、整理しながら、業務をパズルのように組み替えてコードに落とし込んでいく。テストコードはClaudeに書いてもらえばいい。テストに誤りや漏れがあったとしても、モデルの性能が上がっていけば、コードとテストごと改善のループに乗せて直していける、と見ている。
そして、この切り分けの勘どころ、つまりどこまでを決定論的に書き切れるか、どこからをAIに残すかは、プログラミングの知識がないとつかみにくい。
過渡期の担い手
Boris の「エンジニアが常にやってきたことの自然な延長」という締めから察するに、AXの中身はエンジニアがやってきた行為であり、それをAIでドメイン知識ごと取り込みながら広げる話だ。だとすれば、プログラミングエンジニアとしての知識やアプローチを理解していないと難しい、という点にどうしても回帰する。人間側の学習、つまりエンジニア的なアプローチの取り込みは、AIが進歩しても依然として必要だ。
過渡期の今、この立ち位置はまだ空いている。冒頭のマトリクスの右上、いまエンジニアリングをやっている人たちやプログラミングを使える人たちが、AXの担い手になっていくのだろうと思っている。