生成AIで仕事が減らない理由｜AIスキルを自動実行へつなぐ方法

生成AIに企画案を作らせます。出てきた案を読んだら競合を調べさせ、技術的に実現できるかを聞き、最後に評価表へまとめてもらいます。AIの回答が返ってきても、結果が出るたびに次の依頼を考えて入力しているのは、ずっと人間のままです。

指示や判断基準をまとめて繰り返し呼び出せるようにした「AIスキル」を作っても、このチャットの往復が消えるとは限りません。AIスキルは単発の調査をそろえることには役立ちます。しかし、回答を受け取るたびに人間が次の指示を出し、ファイルを貼り直しているなら、速くなったのは一つの工程だけです。

仕事を人の手から離すには、専門家が普段行っている「次は何を確かめるか」という思考を、小さな工程に分けます。全体の実行順を管理する仕組みが、各工程と途中の結果を自動でつなげば、人間がファイルを渡し直す回数を減らせます。公開や送信など外部へ影響する操作の直前で処理を止め、人間が判断する構成を目指します。

専門家がチャットで毎回つないでいる調査や判断を、根拠と未確認点を追える形で自動的に続く仕事へ変えるには、どうすればよいのでしょうか。

AIスキルが答えても、次の依頼を人間が作っている

新しいサービス案を評価するAIスキルを作ったとします。入力は一度です。会社の強みと市場の情報を渡すだけで、候補案と評価理由が同じ形式で返ってきます。毎回ゼロから指示を書く必要はなくなりました。

ところが、担当者は結果を読んだ後で「競合はすでに同じサービスを出していないか」と追加で質問します。次に「自社の技術で本当に作れるか」を調べさせ、根拠が弱ければ別の資料を探させます。最後に複数の回答を表へ移し、採用候補を選びます。

AIスキルは、最初の調査と出力形式をそろえるところまでは役立っています。ただ、回答の出来に関わらず、一件の検討を終えるまでに必要な工程は、担当者がチャットで一つずつつないでいます。これでは手は止まりません。

保存した指示と、自動で続く仕事は別物

AIスキルへ評価項目や出力形式を保存すると、同じ仕事を再現しやすくなります。しかし、スキルが一つの回答を返したところで終了するなら、次の工程は始まりません。

生成AIを使っているのに仕事が減らないのは、人間が毎回依頼文を入力し、資料を貼り、次に何をするかを判断し、結果を別の場所へ転記しているからです。AIは作業の一部を補助しているだけで、業務の開始から完了までを引き受けていません。

自動化できる接続部分を見つける方法は簡単です。回答を受け取った直後に行っている操作を書き出します。追加質問を考える、別の資料を添付する、前の結果をコピーするといった操作を書き出します。さらに、別のSkillを呼ぶ、複数の結果をまとめるといった動きの中で、毎回同じものがないかを探します。

ここで最初に問うべきことは、どのAIが賢いかではなく「次の行動を誰が決めるか」です。

MicrosoftのAgent Frameworkの解説でも、人間が判断して進める構成、あらかじめ定めた順にシステムが進めるワークフロー、モデル自身が次の行動を選ぶエージェントを区別しています。人間が何度も行っている「次の工程を起動する作業」をシステムへ渡し、結果を確認する場面へ人間の時間を使うことが目標です。

長さより、同時に扱う判断を見る

人間の操作を減らすために、複数の調査や評価を一つの長い指示へ詰め込むとどうなるでしょうか。指示の行数が多いこと自体よりも、AIが同時に扱う判断の数が問題になります。

企画案を作りながら競合を探し、技術の実現性を確かめ、根拠の強さまで比べる処理では、前の判断が後ろの判断に影響します。人間なら確認の順番を変えたり、弱い根拠だけを調べ直したりできますが、すべてを一つの回答に押し込むと、どこで判断が浅くなったのかを追いにくくなります。

したがって、指示を足して一つにまとめれば仕事が深くなると考えるのは危険です。機械的に指示をつなぐのではなく、判断の単位で工程を分けます。

仮説を作る工程、競合との差を確かめる工程、実現性の根拠を集める工程を別にすれば、担当者は弱い工程だけを見直せます。次の節では、専門家が次に確かめることをSkillへ入れる方法を見ていきます。

専門家が次に確かめることをSkillへ入れる

AIが出した企画案が一般論にとどまっているとき、ただ「もっと深く考えて」と指示を足すだけでは、専門的な回答になるとは限りません。経験を積んだ専門家は、最初の案を眺めて終わるのではなく、次に確認するべき対象を持っています。たとえば、競合サービスとの違いを確かめ、自社の技術で実現できるかを調べ、根拠が十分かを見てから評価を下します。

この「次に何を見るか」という確認順が人間の頭の中にしかないと、システムは最初の案を出したところで止まってしまいます。その結果、毎回人間がチャットで「競合も見て」「実現性も確認して」と依頼を書き足すことになります。

「何を出すか」だけでなく「次に何を見るか」を書く

専門家が普段どの順で疑い、どこまで確かめたら次の段階へ進むのかを取り出します。

たとえば仮想のサービス評価では、担当者は次のような順番で確認を繰り返しています。まず、会社の資産と顧客の課題からサービスの仮説を作ります。次に、国内外の競合や代替手段を調べて既存案との差を確かめます。さらに、必要な技術や運用体制を確認し、作るうえで越えるべき条件を探します。最後に、各工程の根拠をそろえ、評価基準に沿って候補を比べます。

納得できない回答が出たときは、抽象的な指示を長くするのではなく、実際に専門家が追加で確認した対象と理由をSkillへ組み込みます。

複数の資料を比較したり、内容の違いに応じて調査経路を選んだりする処理では、許可された範囲内でAI自身に手順を選ばせる構成も候補になります。MicrosoftのAgent Frameworkの解説では、モデルが次の行動を選ぶエージェントと、定めた経路を進むワークフローを使い分けています。

分割する単位は、判断と受け渡しで決める

処理を分けるときは、文章の長さではなく、判断の責任が切り替わる場所を基準にします。

各工程には、AIが読む入力、AIが判断すること、次の工程へ渡す出力、条件を満たさないときの戻り先の4点を決めます。

仮説作成の工程では、会社の資産や顧客の課題を入力します。検討する価値がある案かを判断し、仮説と未確認点を出力します。

競合確認の工程では、前の工程で作った仮説と公開資料を読み込みます。既存案との差分や見つからなかった情報を次の工程へ渡します。

これがないと、工程を分けても「次へ進んでよいか」を結局別の人間が判断することになります。競合との差を確認できなければ、検索範囲を広げるか仮説へ戻ります。技術資料が不足していれば、実現性の調査を続けます。このように、結果に応じた次の工程も設定します。

順番や条件を固定できる部分は、あらかじめ定められた経路を進むワークフローに任せます。難しい調査や曖昧な判断が必要な箇所だけを追加で分ける考え方が実務には合います。

このように判断の単位でSkillを分けると、専門家が確認する順番や条件を、短い呼び出しから再利用できる形で残せます。次は、各工程の結果を人間が毎回コピーしなくても済むように、途中の答えを残し、実行環境が次の工程へ渡す方法を見ていきます。

途中の答えを残し、親Skillが次の工程へつなぐ

工程を判断の単位で分けただけでは、まだ仕事は手離れしません。人間が工程のたびに結果を保存し、次のチャットへ貼り付けていたなら、人間の手間が残るからです。各工程がどこへ出力し、次の工程が何を読み込むのかをあらかじめ決める必要があります。

たとえば仮想の企画評価では、仮説作成の結果を別の場所に残し、そこから競合確認や実現性の検討へつなぎます。ここで残すのは、AIが内部で考えた長い文章そのものではありません。事実、根拠、未確認点など、次の工程が必要とする判断材料を明確な形で記録します。これにより、AIが加えた解釈と、出典で確認できる事実を切り分けて追いやすくします。

中間出力を次の工程が読める形にする

中間出力には、次の工程が迷わない見出しを置きます。事実と解釈を混ぜず、判断が保留されている箇所も残すことが大切です。

たとえば、事実をまとめた出力には参照資料や出典URLを含め、何を根拠として使えるかを示します。主張を整理した出力では、対応する根拠を並べて事実と解釈が混ざっていないかを確認できるようにします。評価のメモには反対根拠や矛盾、未確認事項を残してどの判断を保留するかを明記し、統合に向けた出力では、採用項目や出力形式をまとめます。

この形式なら、最終評価が弱いときに、競合確認の事実が不足しているのか、主張に根拠が対応していないのかを切り分けられます。中間出力はAIへ長い会話を覚えさせるための単なるメモではなく、工程どうしが同じ判断材料を読めるようにする受け渡し口です。

親Skillに目次と実行順を書く

全体の流れを示す「親Skill」には、一件の仕事の順番を書きます。親Skillは手順書であり、それだけで別の工程を自動実行するわけではありません。実際の呼び出しと結果の受け渡しは、ファイル操作やツール実行に対応したエージェント、ワークフロー基盤などの実行環境が担当します。

たとえば、最初に仮説作成を呼び出し、出力がそろったら競合確認を呼び出します。競合との差が見つからなければ仮説の作り直しへ戻し、差が確認できたら実現性の検討へ進める、といった流れです。

Microsoft Agent Framework workflowsの説明が示すように、ワークフローはあらかじめ定義した順番や条件分岐に沿ってシステムを進める仕組みです。調査の大枠は固定し、特定の条件下でどの処理へ戻るかを設定することで、毎回すべての指示を入力へ詰め込まずに済みます。

親Skillには、開始条件、読む資料、呼び出す工程、出力先を記述します。その記述に沿って、実行環境側へ呼び出し順、出力先、権限を設定します。工程の順番と受け渡しが実行環境で動くことを試験すれば、利用者が途中のファイルをダウンロードして別のチャットへ投げ直す操作を減らせます。

弱い工程だけをやり直せる

途中の答えをチェックポイントとして残し、各工程を個別に再実行できる構成にすると、弱い工程だけを後からやり直せます。最終評価がおかしいときに、競合調査が弱いのか、実現性の根拠が足りないのかを切り分け、条件が変わっていない他の結果を再利用できます。

LangGraphの永続化の仕組みも、処理の途中状態をチェックポイントとして保存し、後から確認や再開ができる構成を説明しています。さらに、Microsoftのワークフローのチェックポイントに関する資料でも、状態を保存して後から再開する仕組みが重要だと示されています。

ここまでの手順を実行環境へ組み込み、工程間の受け渡しを試験すると、人間が中継するために毎回止めなくても、一件の検討を進められるワークフローを作れます。まずは人間が次の依頼を作っている場所を見つけ、その接続を自動化されたワークフローへ移していくことが第一歩です。

自動でつないでも、外へ出す直前は人間が止める

調査や評価の工程を自動でつなげたからといって、最終結果まで無条件に公開したり、取引先へ送ったりする必要はありません。毎回の中継作業は、親Skillに書いた手順を実行するワークフローへ任せつつ、結果に対する責任や判断は人間に残せます。

仮想の企画評価なら、資料の読み取り、競合の確認、実現性の調査、評価案の作成までは自動で進めます。実行環境には、親Skillに書いた条件に対応する停止処理を設定します。ワークフローは最後に、採用候補、根拠、反対材料、未確認点を一つにまとめて処理を止めます。担当者は提示された判断材料を読み、必要な箇所は出典へ戻って確認したうえで採否を決めます。

止める場所は、外部へ影響する操作の前に置く

公開や送信など、後から取り消しにくい操作は、人間が承認する前に処理を止めます。発注や記録の変更も同じです。AWS Step Functionsの人間による承認を待つ構成が示すように、処理の途中状態を保存したまま待機し、人間の確認後に再開する仕組みを作ります。

このとき、承認画面でただ「承認しますか」と聞くだけではいけません。担当者が結局自分で調査を追い直すことになるからです。AIが実行しようとしている操作、その根拠、確認できなかった点を画面に表示し、人間がその場で判断できる材料までを自動工程でそろえます。

同時に、安全のためにAIがアクセスできる範囲を制限します。OWASPのExcessive Agencyは、AIへ必要以上の機能や権限を与えるリスクを指摘しています。企画評価において必要な権限が、資料の読み取りと評価案の下書き保存までなら、外部への送信機能やデータを削除する権限をAIへ渡す理由はありません。

さらに、人間が承認する前であっても、根拠が足りない、同じ失敗が続く、許可されていない資料が必要になったといった場合には自動で処理を止めます。実行記録には、AIがどの工程を通り、どの資料を参照し、どこで止まったかを後から確認できるように残します。

自動で進める範囲を守るために、開始条件とAIの権限を決めます。さらに、停止条件、承認方法、記録の残し方を設計します。

次の工程へ進むことばかりを優先すると、途中で判断をやり直す場所や、失敗時に人間へ戻す場所が抜け落ちてしまいます。自動化の境界を明確に決めて試験すれば、担当者が手放せる中継作業と、人間が確認する操作を切り分けられます。

では、このように実行をシステムへ渡した結果として、仕事が減ったかどうかはどのように測ればよいのでしょうか。

仕事が減ったかは、往復回数と修正量で測る

実行をシステムへ渡した結果として仕事が減ったかを確かめるために、人間とシステムの往復回数に加え、手動転記、差し戻し、出力の修正量を導入前後で比べます。AIの最終回答だけでなく、仕事を終えるまでに人間が何回呼び戻され、どれだけ手直ししたかを記録します。

まず、チャットの履歴を開き、自動化する前の仕事を一件だけ記録します。質問した回数、渡したファイル、回答をコピーした先、内容を直した箇所を並べます。最後に人間が下した判断も一行で残しておくと、自動でつなぐ作業と人間に残す判断を分けやすくなります。

一工程だけ速くなっていないかを確かめる

導入後は、人間の入力回数とファイルの受け渡し回数を測ります。手動転記、差し戻し、出力の修正量も同じ単位で記録します。仮にAIの処理時間が短くても、担当者が導入前と同じ五回呼び戻されているなら、往復回数は変わっていません。

一方で、最終的な承認が一回残っていても、途中の四回の依頼と転記がなくなり、判断材料が一つにまとまっていれば、人間の繰り返し作業は減っています。NISTの資料が示すように、評価の測定項目は目的に合わせて決めるものです。今回の目的はAIの賢さを採点することではなく、人間が工程をつなぐ回数を減らすことです。

分けないほうがよい仕事もある

工程を細かく分ければ、いつでも結果がよくなるわけではありません。入力が少なく、判断が一つで、失敗した場所もすぐ分かる仕事なら、一つの工程で完結させたほうが読みやすく、実行も速い場合があります。分けた工程の間で同じ資料を何度も読み直したり、短い出力へ変換する作業が増えたりすると、かえって自動化したはずの受け渡しが新しい負担になります。

Anthropicの資料でも、複雑な仕組みを先に作るのではなく、必要な場合だけワークフローやエージェントを組み合わせる考え方が示されています。分ける基準は指示が長いからではなく、判断の責任が切り替わり、結果を別の工程でも検証したいからです。

小さな試験運転から始める

最初は、外部への書き込みをしない試験運転にします。親Skillに書いた手順を実行環境で動かし、各工程の呼び出し、中間出力の保存、最終的な評価案の作成までを試します。担当者は、途中で根拠が欠けた工程、不要だった確認、何度もやり直した工程を見て、処理の順番や判断基準を直します。

生成AIを使っても仕事が減らないと感じたとき、すぐに別のAIへ替える必要はありません。回答を受け取った後に自分が作っている次の依頼を一つ見つけ、その依頼が必要になる理由を仕組みへ書き、結果を残して次の工程へつなぎます。

最初から一件の仕事をすべて自動化しなくても構いません。人間の手作業が多い接続を一つだけ移し、根拠が次の工程へ渡るかを確かめます。うまくいかなければ分割を戻し、うまくいけば次の接続を移します。こう進めれば、人間は単なるチャットの中継役から少しずつ離れ、最後の重要な判断へ集中できます。

よくある質問

Q1. AIスキルとは何ですか？

本記事では、AIへの指示、判断基準、参照資料、実行手順をまとめた再利用可能な手順書を「AIスキル」と呼びます。

複数の工程やツールを順番に動かすには、AIスキルを読み取って実行するエージェントやワークフロー基盤が別途必要です。

Q2. AIスキルを作っても仕事が減らないのはなぜですか？

AIが一つの回答を返した後に、人間が作業を引き取っているからです。

人間が追加質問を考え、新しい資料を渡し、別の工程を呼び出し、結果を手作業で転記しているうちは、工程をつなぐ手間が人間に残ります。

Q3. 専門家の判断をSkillへ入れるには、何から始めますか？

AIの回答を受け取った直後に、専門家が追加で何を確認したかを記録します。

単に「もっと深く考えて」と指示するのではなく、競合の動向や実現性の根拠など、次に確かめる対象と条件を明確にします。

Q4. 中間出力を残すのはなぜですか？

各工程の根拠を、次の工程が正確に読み込めるようにするためです。

最終的な結果がおかしいときに、どの工程からやり直すべきかが分かります。Microsoftのワークフロー・チェックポイントの解説にあるように、途中の状態を保存して後から再開できる仕組みは、工程ごとの確認や再実行に使えます。

Q5. 長いAIスキルは短くすればよいですか？

ただ指示の行数を減らせばよいわけではありません。

仮説の作成や競合の確認など、判断の責任が切り替わる単位で分けます。入力が少なく、一つの判断で終わる単純な仕事なら、一つのままにしておきます。

Q6. 中間出力はAIの内部推論を保存するものですか？

いいえ。AIが内部で考えた過程ではなく、事実、根拠、未確認点などを次の工程へ渡すための成果物として残します。

どの資料をもとにどの判断をしたのか、事実の出どころを追えるようにすることが目的です。

Q7. SKILL.mdには何を書きますか？

スキルの目的、開始条件、読むべき資料、呼び出す工程、出力形式を書きます。あわせて、戻り先、停止条件、権限、承認方法も明記します。

これらの実行ルールをファイルとして整えたうえで、実行環境側にも呼び出し順、連携経路、権限を設定し、想定どおりに動くかを試験します。

Q8. 親Skillは何をしますか？

仕事全体の実行順序、条件分岐、各工程へ渡す情報を記述します。

実際にシステムを進めるのは、その手順を読み、必要なツールを呼び出せる実行環境です。MicrosoftのAgent Frameworkの解説にあるように、基本は固定した経路を進め、根拠不足などの条件に当てはまる場面だけ前の工程へ戻す構成を取れます。

Q9. 分割しても効果がないときはどうしますか？

工程の受け渡しだけが増え、人間の手作業が減らない場合は、分割を戻します。

処理を分ける基準は、指示の長さではありません。それぞれの判断を別々に検証したいか、弱い工程だけをやり直したいかどうかに置きます。

Q10. 人間の確認はどこに残しますか？

公開、送信、発注など、外部へ影響を与えて取り消しにくい操作の直前に残します。

AWS Step Functionsの人間による承認を待つ構成のように、処理の途中状態を保存したまま待機し、人間の確認後に再開する仕組みを作ります。承認画面にはAIの判断根拠や未確認点を一緒に表示し、人間がそのまま採否を決められる状態にします。