人間向けの手順書を、AIエージェントが実行・検証できる形式知へ変換する考え方を解説します。暗黙知の洗い出し、手順の構造化、例外処理の明文化を通じて、自動化と業務標準化を同時に進める進め方を、断定を避けつつ整理しました。
多くの現場に、手順書やマニュアルは存在します。にもかかわらず「この作業は結局あの人しかできない」「担当者が休むと止まる」という属人化が解消されないのは、手順書が足りないからというより、手順書に書かれていない判断が人の頭の中に残っているからだと考えられます。業務改善・品質管理の担当者が標準化に取り組むとき、最初に向き合うべきはこの「書かれていない部分」だと言えます。
一般的に、手順書は物事がうまく進むケース、いわゆる正常系を中心に書かれがちです。「Aの書類を受け取ったらBのシステムに入力し、Cへ回す」といった流れは書いてあっても、「Aの書類に不備があったらどうするか」「Bのシステムがエラーを返したらどう対処するか」「Cの担当者が不在のときは誰に回すか」といった例外系は、明文化されずに個人の経験則に委ねられているケースが少なくありません。属人化の正体は、この例外処理の判断が特定の人に集中していることにあると考えられます。
ベテランの担当者ほど、自分がどんな基準で判断しているかを意識していないことがあります。「なんとなく違和感があったから確認した」「この取引先はいつも数量がずれるので念のため電話した」といった判断は、本人にとっては当たり前すぎて、手順書に書こうという発想にすらなりにくいものです。こうした暗黙知は、質問して初めて言葉になる性質を持つため、放置すると担当者の退職や異動とともに失われるリスクがあります。
人間は文脈から意味を補って読むため、多少あいまいな手順書でも、経験のある人ならそれなりに正しく動けます。しかしこの「補って読める」という柔軟性は、裏を返せば人によって解釈がぶれる余地を残しているということでもあります。標準化の観点では、この解釈の幅こそが品質のばらつきや属人化の温床になり得ます。手順書を、人が読んでもAIエージェントが読んでも同じ結果に到達できる精度まで引き上げること — それが本記事で扱う「コード化」の狙いです。
なお、社内に散在する既存の手順書やマニュアルをまず横断的に参照できるようにする仕組みとしては、社内文書をAIに答えさせる仕組み（RAG）の考え方が出発点として役立つと考えられます。コード化の前に、まず「今ある文書に何が書かれ、何が書かれていないか」を把握する段階として位置づけられます。
ここで言う「コード化」は、必ずしもプログラミング言語で書き起こすという意味ではありません。プログラムを書く人が守っている考え方の型 — あいまいさを残さず、入力と出力と条件分岐を明示する — を、業務手順の記述に持ち込むという発想です。AIエージェントに業務を渡せる形にするうえで、この考え方が土台になると考えられます。
ひとつの作業を、次の四つの要素に分けて記述してみます。第一に、その作業を始めるために何が揃っている必要があるか（入力）。第二に、何をどの順で行うか（処理）。第三に、完了したとき何が出来上がっていれば正しいか（出力・完了条件）。第四に、どういう状態になったら人に判断を仰ぐべきか、あるいは処理を止めるべきか（停止条件・エスカレーション条件）。この四分割は、人が読む手順書としても曖昧さが減りますし、AIエージェントに渡す指示としてもそのまま骨格になり得ます。
コード化の中心にあるのは、暗黙の判断を「もし〜なら〜する」という条件文の形に翻訳する作業です。「違和感があったら確認する」という表現は、そのままではAIエージェントも新人も実行できません。「発注数量が前回実績の±30%を超えていたら、発注元に確認する」「同一取引先で同じ品番が当日中に二重に届いていたら、重複の可能性としてフラグを立てる」というように、判断のトリガーとなる条件を可能な限り観測可能な事実に置き換えていきます。ここで置き換えきれない、真に人間の裁量が必要な部分こそが「人が担うべき仕事」として残ると考えられます。
近年のAIエージェントは、構造化された自然言語の指示を解釈して手順を実行できるようになりつつあります。したがって、必ずしも厳密なフローチャートやコードに落とし込まなくても、上記の四要素と条件文を明快な日本語で書き下すだけで、AIエージェントが解釈しやすい「実行できる形式知」に近づけられる可能性があります。重要なのは記法の厳密さそのものよりも、解釈の余地をどれだけ潰せているかだと考えられます。もっとも、AIエージェントは指示にない部分を推測で埋めることがあり、その推測が誤る場合もあるため、あいまいさを残すほど誤動作のリスクは高まる点には注意が必要です。
この作業の副次的な、しかし本質的な効果は、コード化を進める過程そのものが業務標準化になっているという点です。手順を分解し、判断を条件に落とし、例外を明文化する — これは自動化のための準備であると同時に、人が担う場合でも品質を揃えるための標準そのものです。自動化するかどうかを最終的に決める前でも、コード化された手順書は「誰がやっても同じ結果になる業務」への第一歩として価値を持つと考えられます。
コード化の成否は、頭の中にある暗黙知をどれだけ引き出せるかにかかっていると言っても過言ではありません。ここでは、洗い出しから構造化までの現実的な進め方を整理します。いきなり完璧な手順書を目指すのではなく、実際の作業を観察し、質問を重ねながら少しずつ精度を上げていく姿勢が適していると考えられます。
暗黙知は、机上のヒアリングだけでは出てきにくいものです。担当者に実際の作業を進めてもらいながら、「今なぜそれを確認したのですか」「もしこの数字が違っていたらどうしますか」と、その場の判断を都度言語化してもらう方法が有効だと考えられます。特に「いつもと違うことが起きたとき」の対応こそが例外処理の宝庫であり、正常系の説明だけでは決して表に出てきません。数日から数週間、さまざまなパターンに立ち会うことで、隠れていた分岐が見えてきます。
メールのやり取り、チャットの履歴、対応メモ、クレーム記録といった過去のログには、実際に起きた例外とその対処が眠っています。これらを振り返ると、「こういうケースが年に数回起きて、そのたびに手作業で対応していた」という暗黙のルールが浮かび上がることがあります。こうした過去データの集約と参照については、蓄積データからマニュアルを自動生成するアプローチと組み合わせることで、洗い出しの初期ドラフト作成を効率化できる可能性があります。ただし自動生成された下書きはあくまで叩き台であり、現場担当者による確認と補正が前提になると考えられます。
構造化の過程で見落とされがちなのが、用語の定義です。「至急」「不良品」「未処理」といった言葉が、人によって、あるいは部署によって違う意味で使われていることは珍しくありません。AIエージェントに手順を渡す場合、この定義のぶれはそのまま誤動作につながり得ます。誰が読んでも同じ対象を指すように、判断の基準となる語を具体的な条件で定義し直しておくことが、後工程のトラブルを減らすと考えられます。
すべての手順を同じ細かさで書く必要はありません。全体の流れを示す大きな地図と、個々の判断を示す詳細手順を階層で分け、必要な部分だけ深掘りする構造にすると、作る側も読む側も負担が減ります。AIエージェントに渡す際も、大枠を与えたうえで詳細を参照させる階層構造のほうが、指示が長すぎて焦点がぼやける事態を避けやすいと考えられます。
洗い出した暗黙知を構造化できたら、次はそれをAIエージェントが解釈・実行し、さらに結果を検証できる形に整えていきます。ここでの目標は「渡せば動く」ことだけでなく、「正しく動いたかを確認できる」ことまで含みます。検証の設計を欠いた自動化は、静かに誤り続けるリスクを抱えると考えられます。
AIエージェントに任せた作業が正しく終わったかどうかを判定するには、完了条件が観測可能な事実として書かれている必要があります。「きちんと処理する」ではなく、「対象の全件について、システム上のステータスが『処理済』になっており、かつ金額の合計が入力元の合計と一致していること」というように、機械的に照合できる条件へ落とし込みます。この検証条件は、人が最終確認する場合にもチェックリストとして機能します。
AIエージェントにすべてを任せきるのではなく、「この条件に当てはまったら人に判断を渡す」という境界を明示的に設計することが重要だと考えられます。判断に必要な情報が揃っていないとき、想定外のパターンに遭遇したとき、影響が大きい処理に踏み込むとき — こうした場面では、無理に処理を続けさせるより、いったん止めて人へ回すほうが安全です。どこまでをエージェントに任せ、どこで人が承認するかという線引きは、業務ごとに現物で確かめながら決めていく領域だと言えます。
AIエージェントへの指示（プロンプト）は、いわば新しい手順書そのものです。個人が思い思いに書いた指示が散在すると、せっかくコード化した業務が再び属人化してしまいます。指示の書き方を社内で揃え、良い型を共有していく取り組みは、プロンプトの社内共有と標準化で整理されている考え方が参考になります。手順書のコード化とプロンプトの標準化は、同じ「業務の形式知化」という営みの両輪だと考えられます。
最初から全業務を任せるのではなく、影響範囲の限られた作業で試験的に走らせ、実行ログを人が確認する段階を挟むことを推奨します。エージェントがどこで迷い、どこで想定と違う動きをしたかは、実際に動かしてみて初めて分かることが多いものです。このログこそが、手順書に足りなかった条件や、定義があいまいだった用語を教えてくれる材料になります。検証を前提にした小さな運用が、結果的にコード化の精度を最も早く高めると考えられます。
業務のコード化は有望なアプローチですが、進め方を誤ると「作ったのに使われない手順書」や「かえって手間が増えた自動化」に終わることがあります。ここでは、事前に知っておきたい典型的な落とし穴を挙げます。いずれも、断定的な結論というより、注意しておくべき傾向として捉えていただければと思います。
特に最後の「作れる人の偏り」については、収集・処理を担うエージェントを設計し運用し続けられる人材をどう育てるかという論点が重要になります。この点は収集エージェント・処理エージェントを運用できる人材の育て方で扱われている考え方が参考になると考えられます。
手順書をコード化しただけでは、業務標準化は完成しません。それが現場で使われ、変化に合わせて更新され、運用できる人が増えていって初めて、属人化からの脱却が現実になると考えられます。ここでは、定着のための運用面の勘所を整理します。
コード化された手順書は、完成品ではなく生き物として扱うのが現実的です。エージェントの実行ログや人の確認記録から、想定外だった分岐や、あいまいだった条件を拾い、そのつど手順書に反映していく。この改訂のループが回っている限り、手順書は現場の実態に追随し続けます。逆に、このループが止まった瞬間から陳腐化が始まると考えられます。更新のオーナー（誰が改訂の責任を持つか）を明確にしておくことが、ループを止めないための最低条件だと言えます。
業務の一部をエージェントが担うようになると、人の役割は少しずつ変わっていくと考えられます。一つひとつの処理を自分の手で行うことから、エージェントの結果を確認し、例外を判断し、手順そのものを改善することへ。この移行は評価や役割分担の見直しを伴うため、現場任せにせず、業務改善の担当者が意図を持って設計することが望ましいと考えられます。単なるツール導入ではなく、働き方の再設計として捉える視点が有効です。
コード化された手順、プロンプト、用語定義、過去の例外対応は、散在させず社内のナレッジ基盤に集約し、必要なときに誰もが参照できる状態にしておくことが定着を後押しします。人が参照するためだけでなく、AIエージェント自身が判断の根拠として参照できるようにしておくと、手順書の更新がそのまま業務品質の向上につながりやすくなると考えられます。集約されたナレッジは、標準化の資産であると同時に、次の自動化の出発点にもなります。
すべての業務を一度に標準化しようとすると、負荷が大きく頓挫しやすいものです。まずは属人化のリスクが高く、かつ手順が比較的明快な一業務でコード化を試し、そこで得た型 — 洗い出しの進め方、記述のフォーマット、検証の仕組み — を他の業務へ広げていく進め方が現実的だと考えられます。一つ目の成功体験が、社内の理解と協力を得るうえでの説得材料にもなります。
最後に、業務プロセスのコード化にこれから取り組む場合の、現実的な進め方を段階として整理します。いずれの段階も、一度で完璧を目指すのではなく、現物・現場の業務で検証しながら精度を上げていく前提で捉えていただければと思います。
属人化の影響が大きく、担当者の協力が得られる一業務を選びます。まずは既存の手順書と実際の作業のギャップを、実作業の観察を通じて把握します。この段階では改善案を急がず、「今どう動いているか」と「何が書かれていないか」を丁寧に見ることが土台になります。
観察と質問を重ねて例外処理と判断基準を引き出し、入力・処理・出力・停止条件の四要素と条件文の形に構造化します。用語の定義を揃え、AIエージェントが解釈しても人が読んでもぶれない精度を目指します。
影響の限られた範囲でAIエージェントに実行させ、人がログを確認する運用から始めます。エスカレーション条件を明示し、迷った箇所や誤った箇所を手順書に反映していきます。ここでの検証が、コード化の精度を最も実効的に高める工程になると考えられます。
改訂ループと更新オーナーを定め、ナレッジを集約し、運用できる人材を複数育てながら、得た型を他業務へ広げます。標準化と自動化を、無理のない範囲で少しずつ組織の土台に組み込んでいきます。
ここまで述べてきた進め方は、一般的な考え方の整理であり、実際にどこまでをAIエージェントに任せ、どこで人が判断するかは、業務ごとの現物・現場を見なければ決められない領域が多く残ります。Nsightは、元キーエンス画像処理事業部で製造・物流の現場に向き合ってきた監修者の知見を踏まえ、「まず小さく動かして、現場で確かめる」という姿勢を大切にしています。属人化した業務の標準化に取り組むうえで、どの業務から着手し、どこまでコード化できそうかを、机上の理想論ではなく現物の業務を一緒に見ながら確かめていくことを推奨します。ご関心があれば、現状の業務を題材にした検証から一緒に始められればと考えています。
必ずしもプログラミング言語で書き起こすことを指すわけではありません。ここで言うコード化とは、あいまいさを残さず入力・処理・出力・停止条件を明示し、判断を条件文の形に落とすという「考え方の型」を手順書に持ち込むことを意味します。構造化された明快な日本語であっても、AIエージェントが解釈しやすい実行できる形式知に近づけられる可能性があると考えられます。
多くの手順書は物事がうまく進む正常系を中心に書かれており、不備やエラーが起きたときの例外処理や判断基準が明文化されていないことが多いためだと考えられます。この書かれていない判断が特定の担当者の頭の中に残っている状態が、属人化の主な要因だと言えます。まずは例外系と暗黙の判断基準を洗い出すことが出発点になります。
その懸念は現実的で、AIエージェントは指示にない部分を推測で補うことがあり、その推測が誤る場合もあります。だからこそ、完了条件を観測できる事実で書いて検証できるようにし、想定外の場面では人にエスカレーションする境界を明示することが重要だと考えられます。最初は影響の限られた範囲で人がログを確認しながら小さく試す運用を推奨します。
属人化のリスクが高く、かつ担当者の協力が得られ、手順が比較的明快な一業務から始めるのが現実的だと考えられます。そこでコード化の型 — 洗い出しの進め方、記述フォーマット、検証の仕組み — を確立し、他の業務へ横展開していく進め方が、負荷を抑えつつ成功体験を積みやすいと言えます。
完成品というより、実行のたびに更新し続ける生き物として扱うのが現実的だと考えられます。業務や取引条件は変わり続けるため、エージェントの実行ログや人の確認記録から想定外の分岐やあいまいな条件を拾い、そのつど改訂していくループが欠かせません。更新の責任者を明確にしておくことが、陳腐化を防ぐ最低条件になります。
どの業務から着手し、どこまでAIエージェントに任せられそうかは、現場の業務を見なければ決められない部分が多く残ります。元キーエンス画像処理事業部出身の監修者の知見も踏まえ、まず小さく動かして現物で検証するところから、貴社の業務を題材に一緒に確かめていきます。
業務のコード化について相談する