Agent SDKを業務へ移す：AIに選ばせる手順、固定する条件

問い

コーディングの反復を、月次報告へ持ち込めるか

月次報告を作るAIが、資料を探し、表を整え、見栄えのよいグラフまで作った。 それでも経理担当者は、前年と比較してよい売上なのか判断できない。 返品を差し引いた金額なのか、受注した金額なのかが分からないためだ。 これは本稿の想定例だが、仕事を進める能力と、仕事の条件を守る能力の違いをよく表す。

9月29日のClaude Agent SDKの説明は、Claude Code SDKという名称を改め、コード以外の仕事にも実行の仕組みを再利用する方向を示した。 ファイルやコマンドを扱い、文脈収集、操作、検証を繰り返す。 用途を広げる手掛かりは、財務や調査という業種名よりも、この反復にある。

本稿では、反復を業務に移すとき、何をAIに選ばせ、何を固定するかを考える。 私の判断は、資料の探索や不足の確認には適応する余地を与え、業務の定義と計算条件は明示した処理へ置くことだ。 SDKの再利用価値は、業務ルールを推測させずに、その周囲で必要な手順を選べる点にある。

再利用する仕組み

途中で分かったことが、次の操作を変える

Claude Agent SDKの説明では、ファイルの検索・編集、コマンド実行、外部の道具を組み合わせられる。 別のエージェントに分担して文脈を分け、長い処理では要約で文脈を圧縮する機能も示されている。 アプリを一から同じ仕組みで組み直す負担を減らし、途中の結果を見て次の操作を選ぶための部品になる。

月次報告なら、表の列名が予想と違えば説明資料を探し、必要な値がなければ取得先を変える、といった手順を考えられる。 最初からすべての分岐を書けない場面に、反復の使い道がある。 ただし、検索の経路を変える自由と、売上の定義を変える自由は別だ。 前者を許すために後者まで任せる必要はない。

反復は、検証方法があるほど役に立つ。 SDKの説明は規則による確認、見た目の確認、別のモデルによる評価を挙げるが、モデルによる評価の頑健さには留保も置く。 整ったグラフを見て問題がなさそうだと判断するだけでは、計算に含める取引の条件は確かめられない。 業務へ移すには、どの失敗をどの確認で見つけるかまで具体化したい。

道具の設計

APIを増やす前に、AIが選べる仕事の単位を決める

確認の精度は、呼び出す道具が何を返すかにも左右される。 Anthropicの道具設計の説明は、連絡先を全件返す道具より検索する道具、顧客と取引とメモを別々に取得する道具より必要な顧客情報をまとめる道具を例に挙げる。 限られた文脈へ不要な中間結果を詰めず、仕事の目的に沿って操作を選べるようにする考え方である。

この考え方を月次報告に当てはめるなら、データベースの全テーブルへ自由に問い合わせる道具と、承認済み指標を期間・地域付きで取得する道具は、異なる選択肢をAIへ渡す。 後者でも質問の読み違いは起こり得る。 それでも、組織が共通に使う計算を道具側へ置けば、AIが毎回その計算を作り直す範囲を減らせる。

まとめた道具には、処理の内訳を隠す危険もある。 金額だけを返し、返品データの取得に失敗した事実を伏せれば、短い出力はかえって誤解を招く。 どの指標を使ったか、どこまで取得できたか、不足があるかは、次の処理を変える情報として返す必要がある。 これは本稿の設計上の提案であり、短い応答なら常に精度が上がるという主張ではない。

意味を固定する

「売上」の定義を、毎回の生成から切り離す

Looker MCP Serverの発表は、AIがLookerのセマンティックレイヤー、つまり指標を共通に定義する仕組みへ接続する構成を示す。 AIが独自にSQLを組み立てる代わりに、Looker側が定義に沿ってSQLを生成する。 実行ループが依頼の読み取りと道具の選択を担い、指標の計算は既存の定義へ委ねる分担を作れる。

それでも、定義済みの指標を選べば仕事が終わるわけではない。 国内売上という依頼が、配送先の国を指すのか、販売会社の所在地を指すのかで対象は変わる。 期間にも受注日、請求日、売上計上日という違いがある。 この想定例では、指標の候補と依頼の目的を照合し、曖昧さが残れば確認する必要がある。

指標が正しくても、別の定義で作った前年の数値とそのまま比較すると、増減の意味を取り違え得る。 使った指標、期間、地域条件、参照した定義版を報告へ残すことが有用だ。 定義版の取得や記録は、本稿がアプリに提案する実装であり、Looker MCPがこれらを必ず一式で返すとは限らない。 この分担で固定できるのは計算の意味であって、売上が変化した原因までではない。

検証の限界

構文が通ることと、意図した条件を守ること

定義を守る確認が必要な理由は、更新する道具を見ると分かりやすい。 GoogleのFirestore向けMCP Toolboxの説明は、照会、対象文書の更新、セキュリティ規則の検査を扱う。 開発者Alexが20件のテストアカウントを調べ、ほしい物リストから不要な商品を除く話は、明示された仮想例である。 「数時間が数分になる」という結びも、実測した導入成果としては読めない。

この例の規則検査は、欠けたセミコロンを見つける。 続いてAlexは有効な規則を取得して、新しい規則と比べる。 構文の修正と規則の照合が別の手順になっている点が重要だ。 構文が通っただけでは、意図した利用者だけが文書を読めることや、正しい商品だけを削除したことまでは確認できない。

月次報告でも、SQLが実行できること、計算が定義に従うこと、依頼に合うことは別々に確認したい。 確認の一つに成功したことを、残りにも成功した証拠として使わない。 その上で、許可される入力と更新範囲を道具側で制限し、守れない条件をエラーとして返す。 AIの再試行は、その制限を回避する方法を探すためでなく、不足を補って同じ条件を満たすために使う。

処理の分担

柔軟な探索を、決められた順序の中で使う

この分担は、SDKを選ぶ際にも手掛かりになる。 10月1日のMicrosoft Agent Frameworkの発表は、モデルが進め方を決めるAgent Orchestrationと、業務ロジックが手順を決めるWorkflow Orchestrationを分けて説明する。 自由に進める作業と、決められた処理を共存させる方向である。

月次報告の想定例なら、対象期間と指標の確認、定義に沿った集計、検算、下書き作成、確認者への提出という順序を固定する。 各段階の資料探しや説明の作成には、AIが手順を選ぶ余地を残せる。 返品データが欠けた場合はゼロとして集計せず、不足を示して止める。 別の資料を探しても見つからなければ、同じ不完全な値で報告を完成させず、担当者へ確認を渡す。

この構成で確認者が見るのは、最終文面だけではない。 指標と対象範囲、検算結果、未解決の点を見て、提出できる条件を満たすか判断する。 ただし、こうした確認が人の負担を減らすかは検証が必要だ。 記録が大量にあるだけでは、見落としが減るとは限らない。 自動で確かめた部分と人の判断が必要な部分を、報告の根拠に沿って見せたい。

Microsoftの発表は、Microsoft 365 Agents SDKとの統合や共通のクラウド実行環境を将来の方向としても述べる。 それらをすべて現在の既定機能と扱うことはできない。 他のSDKも同じ処理の分担や停止を備えるとは限らず、実際に使う版で確認する必要がある。

選ばない条件

手順が既知の集計へ、反復を増やす必要はない

どの仕事にもSDKを入れる、という結論にはならない。 Anthropicのエージェント設計の説明も、複雑な構成を先に選ばず、必要に応じて単純な構成から進む考え方を示す。 毎月同じ形式のファイルを同じ定義で集計するだけなら、既存のスクリプトで処理し、例外だけを人に渡す選択肢がある。

SDKを検討する理由が強くなるのは、資料の形式や保存先が変わり、途中の情報から次の操作を選ぶ必要がある場合だ。 同じ計算を何度もモデルに作らせることとは異なる。 比較では処理時間だけでなく、誤った指標を選ぶ件数、不足データで停止できる割合、担当者が調べ直す時間まで確かめたい。 追加した自由が成果につながらなければ、固定処理へ戻す判断も残る。

判断

汎用化するのは、業務の条件を守りながら進める方法

Claude Agent SDK、業務向けのデータ接続、Microsoft Agent Frameworkは、異なる場所から実行を再利用する手段を広げている。 それぞれの機能や用途例は、業務全体を任せてよい証明ではない。 比較から読み取れるのは、探索、定義、固定された手順を別々に設計し、組み合わせる余地が増えていることだ。

月次報告へ移すなら、AIには不足を見つけて確認する仕事を与え、売上の定義や提出条件を反復の中で書き換えさせない。 その分担ができて初めて、コーディングで使った仕組みを別の仕事へ持ち込む意味が生まれる。 SDKの価値は、何でもできるという用途の数より、どこまで任せてよいかを具体的に定められるかで判断したい。