Kognitosに業務を任せる前の確認項目｜手順書と承認の線

「RPAのロボットが画面の変更のたびに止まり、保守の担当がもう回らない」「自然言語で書けるAIの自動化に置き換えたとして、経理の処理を監査で説明できるのか」——経理や業務改革を担う部門で、2026年に入って同時に聞かれるようになった二つの声です。2026年10月21日、米国の Kognitos は、経理と銀行の業務向けに「AI Employees」を投入し、61の役割と515本の手順書を用意したと発表しました。8月4日には、取引先・請求書・勘定科目・承認の階層を一つの地図にまとめる経理向けのコンテキストグラフも発表しています。ただし、手順書を自然言語で書けることは、規則の管理が要らなくなることではありません。手順書そのものが会社の業務規則になる、ということです。この記事では、Kognitos に業務を任せる前に確かめておく項目を、つまずきの原因と対策の順に整理します。

Kognitos は何をする製品か：自然言語の手順書を決まった順に実行する基盤と、2026年の動き

Kognitos は2020年に創業した米国カリフォルニア州の会社で、業務の手順を平易な英語で書くと、それがそのまま実行される自動化基盤を提供しています。公式の用語解説は、この方式を英語をそのままプログラムとして扱う、特許を取得した方式と説明し、書かれた規則を記号処理の実行部が決まった実行計画に置き換えて動かすとしています。同じ入力からは毎回同じ出力が出る、というのが同社の主張の中心です。

もう一つの特徴が、公式が「ニューロシンボリック」と呼ぶ二層の構成です。請求書のPDFやメールのような形の決まっていない文書を読む部分は生成AIのモデルが受け持ち、読み取った値をどう処理するかの規則は、決まった順に動く実行部が受け持ちます。10月の発表文も、モデルは文書と依頼を読み、手順書の実行は決まった処理の仕組みが行うと書いています。つまり、AIのモデルが関わるのは読み取りの段で、処理の判断そのものはモデルに任せない設計です。

接続先として、公式のよくある質問は SAP、オラクル、Workday、ServiceNow、Salesforce などを含む200以上の既製の接続部品を挙げ、PDF、メール、銀行の取引明細、企業間の電子データ交換も取り込めるとしています。創業者で最高経営責任者のビニー・ギル氏はクラウド基盤の会社で最高技術責任者を務めた人物で、出資者にはコースラ・ベンチャーズなどが名を連ねます。日本語で読める紹介記事はまだほとんどなく、検討の材料は英語の公式情報が中心になります。

2026年の動き：経理向けのコンテキストグラフと「AI従業員」

2026年8月4日、同社は米ラスベガスで開かれたAIの展示会に合わせて、経理向けのコンテキストグラフを発表しました。取引先、請求書、勘定科目、原価部門、承認の階層、社内の規程、統制の基準額と、それらの関係を一つの生きた地図として持たせ、経理のエージェントがその地図の上で動くという構成です。最初の対象は買掛金、つまり仕入先への支払いの業務で、ほかの経理領域へ広げる計画だとしています。現場に暗黙に残っている例外の扱いも地図に取り込み、規程が変わったときにはモデルを学習し直さずに見直せる、と説明しています。

10月21日には「AI Employees」を投入しました。発表によれば、買掛金、照合、入金消し込み、月次決算、本人確認などの61の役割を用意し、その裏に515本の手順書を置いています。各役割には職務記述、承認済みの手順書、人の承認なしに実行してよい操作の上限、引き継ぎの責任が定義されます。手順書を下書きする作成役のエージェント「クイル」と、つないだ業務システムから業務の地図を作る役のエージェントも用意され、14の領域・62の工程にまたがる133の監視項目を、ワンクリックで常時の統制に変えられるとしています。

読み方の注意があります。一つは、AI従業員とコンテキストグラフが既存の顧客向けのプレビュー（先行提供）という扱いで、一般提供ではない点です。もう一つは、ガートナーの報告書で代表的な企業の例に挙げられた、業界の調査会社の購買ガイドで首位だった、といった評価は、いずれも同社の発表に載っているものだという点です。評価が並ぶことは、自社の業務に合うことを意味しません。今の契約で使える範囲と、これから提供される範囲を分けて聞くことが出発点です。

つまずきの全体像：RPAを置き換えても、同じ止まり方が残る

RPAの代わりに Kognitos を検討する会社の多くは、画面の変更で止まる、保守を一人の担当が抱えている、という悩みから入ります。画面の操作に頼らない方式に替えると、たしかに画面の変更では止まりにくくなります。ただ、RPAが社内で問題になった理由は、画面の変更だけではありませんでした。ロボットの中身を誰も説明できない、規程が変わっても誰も直さない、例外の処理が担当者の頭の中にしかないという管理の問題が、もう一つの根でした。

自然言語の手順書は読みやすいので、この管理の問題が解けたように見えます。しかし読みやすいことと、正しいと誰かが保証していることは別です。手順書が業務の規則そのものになる以上、規則を書き換える権限、例外に答えて新しい規則を増やす権限、その規則のもとでAIに実行させる権限を、それぞれ誰が持つかを決めなければ、止まり方が変わるだけで、管理の問題はそのまま残ります。

RPAとAIエージェントのどちらに寄せるかという一般的な使い分けは別の記事で扱っているので、ここでは繰り返しません。この記事が扱うのは、Kognitos を選んだ後、あるいは選ぶ直前に起きやすい四つのつまずきです。手順書の持ち主の不在、例外の回答がそのまま規則になること、AI従業員という呼び名による権限のあいまいさ、そして読み取りの誤りの扱いです。次の4つのセクションで原因を、その後のセクションで対策を順に見ていきます。

原因1：誰でも書ける手順書は、誰も責任を持たない手順書になりやすい

公式のよくある質問は、手順書を書くのは業務の担当者や工程の持ち主で、開発者は要らないと説明しています。現場が自分で業務の規則を書けるのは大きな利点です。その一方で、経理の現場で「支払いの前に発注書と納品書を照合する」と書いた一文は、内部統制の上では統制手続きの一つです。統制手続きを現場の誰かが自由に書き換えられる状態は、監査の観点からは避けたい状態です。

公式の用語解説は、規則ごとに版と書いた人が記録され、文書として書き出して版管理の仕組みに登録できる、規則は顧客側の既存の変更承認の流れを通してから本番に上げる、役割ごとに編集できる規則の範囲を絞れる、と説明しています。つまり仕組みとしては変更管理を組める製品です。問題は、仕組みがあっても、承認の流れを社内で決めていなければ、誰でも上げられる状態のまま運用が始まることです。

• 手順書の作成を現場の担当者に任せ、本番に上げる承認者を決めないまま試行を始める
• 作成役のエージェントが下書きした手順書を、内容を読まずに承認ボタンだけ押して本番に上げる
• 規程の改定と手順書の改定を別々の部署が持ち、どちらが先に変わったのか誰も追えなくなる
• 退職や異動のあとも、手順書の持ち主の欄が前任者の名前のまま残っている

原因2：例外への回答が、承認を経ずに規則へ変わってしまう

Kognitos の特徴の一つが例外の扱いです。手順書の想定から外れる案件が来ると、実行は失敗せずに一時停止し、担当者に平易な言葉で問い合わせます。人が答えると、エージェントは途中の状態を保ったまま再開します。公式のよくある質問は、この回答が再利用できる規則として保存されると説明しています。例外への対応がその場限りで消えず、次から自動で処理されるのは便利です。

ただ、ここに落とし穴があります。例外に答えた担当者の判断が、そのまま次からの規則になるからです。たとえば「この取引先は請求書の宛名が旧社名でも支払ってよい」と一度答えれば、以後の同じ例外は人を通らずに進みます。その答えが正しかったか、規程に照らして許されるのかを確かめる人がいなければ、現場の一人の判断が、承認を経ないまま会社の規則になることになります。

この点について、10月の発表は、人の回答が将来の実行の指針になるのは承認者が署名した後だけだ、と明記しています。製品の側に一段の関門があるということです。そのうえで社内で決めるべきなのは、例外に答える人と、その答えを規則として認める人を分けるかどうかです。答える人は案件をよく知る現場の担当者、認める人は規程を持つ部門の責任者、という分け方が基本になります。

原因3：「AI従業員」という呼び名が、権限の範囲をあいまいにする

10月の発表で同社は、役割ごとのエージェントを「AI Employees」、つまりAI従業員と呼んでいます。買掛金の担当、照合の担当、決算のとりまとめといった職名が付き、職務記述も用意されます。人の組織に重ねて考えやすくなる半面、人の従業員と同じように、ひとまとまりの権限を渡してよいと誤解しやすいのが注意点です。

人の担当者であれば、職務規程と、上司の目と、本人の常識が権限の使い過ぎを止めます。AI従業員を止めるのは、手順書と、実行してよい操作の上限の設定だけです。公式の役割の説明は、どの操作を単独で実行させ、どの操作に人を通すかを選べるとし、支払いの実行と仕訳の承認は既定で人に残す、役割は職務分掌の線で分ける、としています。既定が人に寄っているのは良い設計ですが、既定はあくまで出発点です。

もう一つ見落としやすいのが、AI従業員がどの資格で業務システムにつながるかです。人の担当者のIDを借りてつなぐと、その担当者が持つ権限すべてをAI従業員も持つことになり、記録の上でも人とAIの操作が区別できません。AI従業員には専用のIDを発行し、その役割の手順書に必要な権限だけを付けるのが原則です。画面の操作を代わりにさせるときの認証情報の預け方は別の記事で扱っているので、ここでは役割ごとにIDを分けるという一点にとどめます。

原因4：読み取りの誤りは、決まった処理の手前で起きる

決まった順に実行する仕組みは、同じ入力に対して毎回同じ結果を返します。ただし、その入力を作るのは文書を読むAIのモデルです。請求書の金額や支払期日、取引先名の読み取りを誤れば、後の処理がどれほど正確でも、誤った値を正確に処理することになります。決まった処理だから誤りが出ない、という理解は半分しか正しくありません。

10月の発表文は、15のモデルを18か月にわたって調べた研究を引き、精度は上がっても、同じ作業を繰り返したときに結果がぶれる問題はほとんど改善していない、と述べています。同社はこれを、処理の実行をモデルに任せない理由として挙げています。この見方に立てば、残る誤りの多くは読み取りの段に集まります。確認の手間は、処理の段ではなく、読み取った値と元の文書の突き合わせに寄せるのが合理的です。

読み取りの誤りを見つける手がかりは、製品の側にもあります。発表では、同じ取引先に二重に支払っていないかといった問いを、常時の監視項目として動かせるとしています。ただ、監視項目が拾えるのは型の決まった誤りです。手書きの訂正が入った請求書、通貨の違う請求書、取引先が社名を変えた直後の請求書のように、型に乗りにくい文書は、最初から人の確認に回す条件として手順書に書いておくほうが安全です。

対策1：手順書ごとに持ち主・承認者・変更の手順を決める

最初の対策は、手順書を社内規程と同じ扱いにすることです。手順書ごとに、内容に責任を持つ持ち主、本番に上げることを認める承認者、規程が変わったときに手順書を直す担当を決め、一覧にします。持ち主は業務を一番よく知る部門の責任者、承認者は内部統制を見る部門か経理の責任者、というように、書く人と認める人を別の人にするのが基本です。

作成役のエージェントが下書きした手順書も、同じ扱いにします。公式の説明では、作成役はつないだ業務システムと直近の取引を調べ、書かれた規程と照らして手順書の下書きを作り、人が承認するまで公開されません。下書きが実際の取引から作られる以上、今の現場のやり方が規程とずれていれば、そのずれも下書きに入り込むことがあります。承認者は、下書きを規程と突き合わせて読み、どこが規程どおりで、どこが現場の慣習なのかを確かめてから承認します。AIに下書きさせるときは、各手順の根拠となる規程の条項を併記させると突き合わせが速くなります。

変更の手順も決めておきます。公式の用語解説は、本番に上げる前に過去のデータで規則を試す環境と、上げるたびに回す回帰試験の仕組みを挙げています。社内では、変更の申請、試験環境での確認、承認、本番への反映、変更の記録という流れを決め、規程の改定日と手順書の改定日が並んで見える台帳を一つ持つと、監査のときに説明しやすくなります。

対策2：例外に答える人と、答えを規則として認める人を分ける

例外の問い合わせは、案件を一番よく知る担当者が受けるのが効率的です。一方で、その答えを次からの規則として認めるのは、規程を持つ部門の責任者に寄せます。製品の側にも、回答が将来の実行に反映されるのは承認者の署名の後、という関門があるので、社内ではその承認者の席に誰を座らせるかを決めることになります。

例外は三つに分けて扱うと運用しやすくなります。一度限りの例外は、その案件だけを処理して規則にはしない。繰り返す例外は、答えを規則の候補にして承認に回す。規程そのものが現実に合っていない例外は、手順書ではなく規程の見直しに回す。三つ目を手順書の追記で済ませると、規程と手順書が少しずつ離れていくので、規程の持ち主に必ず戻します。

例外の件数そのものも見ておくべき指標です。導入から数か月たっても例外の件数が減らない手順書は、業務の実態に合っていないか、読み取りの誤りが多いかのどちらかです。AIに例外の理由を分類させる場合も、分類の結果をそのまま信じるのではなく、分類の根拠になった文書の箇所を併記させ、月に一度は人が抜き取りで確かめるようにします。

対策3：単独で実行してよい操作を、一つずつ決めて広げる

公式の説明では、どの操作をAI従業員に単独で実行させ、どの操作で人を通すかを、操作ごとに決められます。この設定は、導入の最初は狭く、実績を見ながら広げるのが原則です。最初の段階では、読み取り、照合、下書きの作成までを単独にし、外に出る操作と取り消しにくい操作は、すべて人の承認を通すところから始めます。

操作の種類	例	最初の扱い	広げる条件
読む・照合する	請求書の読み取り、発注書と納品書の突き合わせ	単独で実行	読み取りの抜き取り確認で誤りが一定以下
社内に書き込む	会計システムへの仕訳の下書き、取引先の情報の更新	下書きまで単独、確定は人	数か月の記録で差し戻しが少ない手順に限る
外に出す	取引先への問い合わせメール、督促の連絡	人の承認を通す	文面の型を固定し、宛先の範囲を絞れた場合のみ
取り消しにくい	支払いの実行、仕訳の承認、取引先の口座の変更	人に残す	原則として広げない

表の最後の行は、どれほど実績が積み上がっても人に残すのが基本です。特に取引先の口座情報の変更は、なりすましの請求で狙われやすい操作です。公式も支払いの実行と仕訳の承認は既定で人に残すとしていますが、口座の変更のような、支払いの手前の操作も人に残すかどうかは、社内で明示して決める必要があります。

対策4：実行記録を誰が、どの周期で読むかを決める

発表によれば、AI従業員の実行ごとに、英語で読める実行の日誌が残ります。業務システム、銀行、受信箱への呼び出しの一つひとつについて、入力、出力、使った手順書の版が記録され、監査人は任意の取引を選んで一歩ずつ再実行できると説明されています。公式のよくある質問も、自動で行った判断を最低12項目の形式で記録すると書いています。記録が残る仕組みは揃っています。

問題は、記録は読まれなければ統制にならないことです。月次の締めの前に例外と差し戻しの記録を経理の責任者が読む、四半期ごとに内部監査が抜き取りで取引を再実行する、手順書の版が変わった月は変更前後の処理結果を比べる、というように、読む人と周期を先に決めておくことが対策になります。

監査での扱いには注意が要ります。公式の用語解説は、実行の記録が大手監査法人に米国の内部統制の一次的な証拠として受け入れられている、と主張しています。ただしこれは米国の制度についての同社の説明です。国内の内部統制報告制度のもとで同じ扱いになるかは、自社の監査人に、導入前に記録の見本を見せて確かめるのが確実です。

何が社外に出るか：データの置き場と、外のAIからのつなぎ方

Kognitos はクラウドで提供される製品です。公式のよくある質問は、アマゾンのクラウド上で動き、地域を選べること、欧州とアジア太平洋のデータ所在の選択肢があること、通信中と保存時に暗号化し、顧客ごとに分離し、共有のモデルの学習には使わないことを挙げています。認証の面では、SOC 2 の運用評価の報告書、ISO/IEC 27001 の取得、ISO/IEC 42001 への対応を2026年に進めていることを記載しています。

読み取りに使う生成AIのモデルがどの会社のものかは、公開ページでは確かめられませんでした。請求書や銀行の取引明細には、取引先の担当者名や口座番号が含まれます。読み取りの段で文書がどのモデルに渡り、そのモデルの提供元に何が残るかは、契約の前に書面で確かめる項目です。日本の取引先の個人情報が海外の拠点で処理される場合は、委託や越境の扱いを法務と確認しておく必要があります。

もう一つの経路が、外のAIからのつなぎ方です。10月の発表では、コンテキストグラフに REST と MCP でアクセスでき、呼び出す側の権限の範囲で使えるとしています。社内で使っている Claude や ChatGPT から経理の地図に問い合わせられるのは便利ですが、呼び出す側のAIに誰の権限を持たせるかで、見える範囲が決まります。外のAIをつなぐのは、AI従業員の運用が落ち着いてから、読むだけの権限で始めるのが無難です。

使いどころ：経理・受発注・マーケ事務のどこから始めるか

公式の役割一覧を見ると、用意の度合いには差があります。経理の買掛金の担当は11本の手順書がすべて「すぐ使える」状態で、受注管理、請求、入金消し込み、督促の担当も手順書がそろっています。購買の担当は4本のうち3本が使える状態です。一方で、銀行向けの手順書はすべて自社と一緒に作る扱いで、マーケ関連の二つの役割、キャンペーンの運営とお客様の分析の担当も、手順書はすべて未完成です。

始めやすいのは、支払いの前の工程です。請求書の受け取り、読み取り、発注書と納品書との照合、承認者への回付までは、規程がはっきりしていて、記録の価値も高い領域です。受発注では、注文書の読み取りと受注の登録、出荷と請求の突き合わせが候補になります。どちらも、最後の確定と支払いは人が持ち、その手前の照合と下書きを任せるという分け方が取りやすい業務です。

マーケ事務では、展示会やウェビナーの請求書の照合、広告代理店や制作会社への支払いの前の確認、販促物の発注と納品の突き合わせなど、経理の型に近い業務から考えるのが現実的です。キャンペーンの企画や対象の選定のように判断を含む業務は、手順書が未完成なうえ、AIに判断させない領域でもあります。マーケ部門が使う場合も、まずは支払いと発注の周辺の事務に絞るのがよいでしょう。

費用の増え方と、やめ方

公式のよくある質問によれば、料金はロボットの台数や利用者の人数ではなく、処理する取引の量とエージェントの複雑さに応じて増える従量の考え方で、公開の価格表はありません。契約は年単位か複数年で、試行には短い期間の契約もあるとしています。無料で試せる作業環境があり、企業向けの概念実証は14日から30日ほどと説明されています。取引の量に連動して費用が増えるので、対象の業務を広げる前に、件数の見込みと上限を決めておくことが欠かせません。

やめ方も先に考えておきます。公式の用語解説によれば、手順書の規則は文書として書き出して版管理の仕組みに登録できます。これは乗り換えの際の大きな利点で、少なくとも業務の規則が製品の中に閉じ込められることは避けられます。ただし、書き出した文書は同社の実行部向けの書き方なので、別の仕組みに移すときは書き直しが要ると考えておくべきです。

やめるときに止まるものも洗い出しておきます。例外の問い合わせへの回答が積み上がった規則、監視項目、実行の記録の保存先、業務システムとの接続です。特に実行の記録は監査の証拠になるため、契約終了後にどの形式で、何年分を引き取れるかを契約の時点で確かめておきます。止めた日から、支払いの前の照合を人の手に戻す手順も、試行の段階で一度書いておくと安心です。

Kognitos に業務を任せる前の確認項目

ここまでの原因と対策を、導入を決める会議で確かめる項目にまとめます。上から順に、すべてに答えが出てから本番に上げるのが目安です。

• 対象の業務の手順書ごとに、持ち主・承認者・改定の担当が決まっている
• 作成役のエージェントの下書きを、規程と突き合わせて読む人と時間が確保されている
• 例外に答える人と、その答えを規則として認める承認者が分かれている
• AI従業員の役割ごとに専用のIDがあり、人の担当者のIDを借りていない
• 単独で実行してよい操作と人を通す操作が、操作ごとに一覧になっている
• 支払いの実行、仕訳の承認、取引先の口座の変更が人に残っている
• 型に乗りにくい文書を人の確認に回す条件が、手順書に書かれている
• 実行の記録を読む人と周期、監査人への見本の提示が決まっている
• 読み取りに使うモデルの提供元と、データの所在・保存を書面で確かめた
• 取引の量の見込みと費用の上限、契約終了後の記録の引き取り方が決まっている

• AI従業員とコンテキストグラフは、2026年10月の発表時点で既存の顧客向けのプレビューです。契約の時点で使える範囲を必ず確かめてください。
• 本記事の機能や数字は、同社の公式サイトと発表文に基づきます。効果の数字は同社の主張であり、第三者の検証を経たものではありません。

よくある質問

RPAをすべて Kognitos に置き換えるべきですか

一度に置き換える必要はありません。画面の変更で止まりやすく、文書の読み取りが多い業務から移し、安定して動いているRPAはそのまま残すのが現実的です。置き換えの順番は、止まる頻度と例外の多さで決めると、移した効果を測りやすくなります。

手順書は英語で書く必要がありますか

公式の説明は平易な英語で手順を書く方式を前提にしており、日本語の手順書がどこまで同じように扱えるかは、公開ページでは確かめられませんでした。日本語の請求書や社内規程を扱う場合は、読み取りの精度と手順書の書き方の両方を、概念実証で実際の文書を使って確かめる必要があります。

AIのモデルが誤って読んだ場合、責任は誰にありますか

製品はあくまで道具で、支払いや記帳の責任は導入した会社に残ります。そのため、誤りが起きても支払いの前に止まる位置に人の確認を置くことが大切です。誤りの原因が読み取りか手順書かを記録から切り分け、手順書の持ち主が直す流れにしておきます。

まとめ

Kognitos は、自然言語の手順書を決まった順に実行し、例外を人に戻す自動化基盤で、2026年8月の経理向けコンテキストグラフ、10月のAI従業員で、経理と銀行の業務に一気に踏み込みました。読み取りはAIのモデル、処理の実行は決まった仕組み、という分け方は、AIに判断させない設計として筋が通っています。けれども、手順書を誰が持ち、例外の答えを誰が規則として認め、AI従業員にどこまで単独の操作を許すかは製品が決めてくれません。手順書の台帳と承認の流れを決め、外に出る操作と取り消しにくい操作を人に残し、記録を読む人と周期を決めてから、支払いの前の照合のような小さな業務で始めるのが、任せる前の確認の要点です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。