生成AIのAPI費用を業務別に配賦し、DXの成果を見える化する物語

月末の夕方、青葉製作所の会議室で、紬は生成AI APIの請求書と部門別の予算表を並べていた。窓の外は青く暮れ、廊下の照明が、かすかに低い音を立てていた。 紬は経理の仕事を、ていねいにする人だった。領収書は日付順にそろえる。予算表の数字は、前月の記録と一つずつ見比べる。小さな差も、そのままにはしない。 「今月も、ここだけが空いているのね」 彼女は予算表の右端を指でなぞった。 営業部。カスタマーサポート部。開発部。 部門名は並んでいる。けれど、生成AI APIの欄には、会社全体の利用量と総額しかなかった。 請求画面には、利用したモデル名と合計のトークン数が表示されていた。トークンとは、AIが文章を読むとき、また文章を作るときの細かな単位だ。日本語の文章も、そのまま一文字として数えるのではない。 「全社で、これだけ使ったことは分かる。でも……」 紬は、営業部の予算表を開いた。 昼間、営業の美咲が、取引先へ出す提案書の下書きを生成AIに頼んでいた。製品の特徴と過去の導入事例を入力すると、長い文章が返ってくる。 「紬さん、昨日の下書き、助かりました」 昼休み、美咲はそう言っていた。 「でも、文章の言い回しを変えるたびに、またAIへ送っているんです。使った回数は、たぶん多いです」 その声が、紬の耳に戻ってきた。 次に、カスタマーサポート部の表を開く。 こちらでは、届いた問い合わせを種類ごとに分けていた。注文内容、納期、製品の使い方。担当者は問い合わせ文をまとめてAIに渡し、返答の下書きを作っている。 「一度にたくさんの問い合わせを整理することもあります」 サポート担当の結衣は、そう話していた。 「回数は少なくても、送る文章が長い日があります」 最後に、開発部の表を開いた。 蓮は、社内の小さな打ち合わせで、生成AIにコードの下書きを頼っている。エラーの説明を送り、修正案を受け取る。関連するファイルをまとめて渡すこともある。 同じ「一回の呼び出し」でも、中身は同じではない。 短い問い合わせを分類する一回。長い仕様書を読み、コードを返す一回。提案書を何度も書き直す一回。呼び出し回数だけでは、費用の大きさを並べられない。 紬は請求書の利用明細を拡大した。 「入力トークン数……出力トークン数……」 画面の下には、費用の計算方法が小さく表示されていた。 入力トークン数×入力単価＋出力トークン数×出力単価。 入力単価は、AIへ渡した文章にかかる。出力単価は、AIが返した文章にかかる。どちらも使った量に応じて増える仕組みだ。 紬は、電卓を手に取った。だが、部門名のない数字では、計算を始めることもできなかった。 「この費用は、どの部門のものですか」 会議室のドアを開けると、開発部の蓮が廊下を歩いていた。紬は声をかけた。 蓮は少し考え、静かに首をかしげた。 「APIを呼び出した記録はあります。でも、業務の名前までは付けていません」 「呼び出した記録には、誰が使ったかは残っていますか」 「システムの処理名や時刻はあります。ただ、営業の提案書なのか、サポートの整理なのか、開発のコード生成なのかは、同じ場所から呼んでいます」 蓮は自分のノートパソコンを開いた。画面には、成功した処理と失敗した処理が時刻順に並んでいた。 「このログなら、何回呼んだかは追えます。でも、入力がどれくらい長かったか。返ってきた文章がどれくらいだったか。そこまで部門ごとには分かれていません」 紬は画面を見つめた。 OpenAIのようなAPI事業者の管理画面には、全体の利用量がまとまっている。会社がAnthropicやGoogle Gemini APIも使えば、請求の場所や集計の単位は、さらに分かれることがある。けれど、どのサービスを使っていても、社内の業務名が自動で付くわけではない。 「つまり、請求書にない名前を、こちらで記録しないといけないのね」 「そうですね。呼び出すときに、部門や業務を示す印を付ければ、あとから追いやすくなります」 「印……？」 「たとえば、営業部の提案書なら、営業・提案書。サポートなら、問い合わせ整理。開発なら、コード生成です。APIキーやプロジェクトを分ける方法もあります」 蓮は、三つの箱を紙に描いた。 「箱ごとに使う場所を分ければ、費用も近いところへ入れられます」 紬は予算表へ視線を戻した。そこには部門名がある。請求書には、数字がある。けれど、その二つをつなぐ橋がなかった。 「来月の予算会議で、総額だけを見せても、誰も使い方を話せないわね」 「使ったことが悪いのではなく、何の仕事に役立ったかが見えないんです」 蓮の言葉に、紬は小さくうなずいた。 会議室には、空調の音だけが残った。紬は請求書を閉じず、余白に鉛筆を置いた。そして、ゆっくりと書き込んだ。 「誰の、何の仕事か」

翌朝、青葉製作所では、生成AI APIの費用が前月より増えたことが分かり、急きょ会議が開かれた。紬は、印刷した請求明細を胸に抱えて、会議室へ急いだ。 朝の光が、長い机の上に細く伸びていた。営業部の真帆。サポート部の由衣。開発部の蓮。経営企画の戸田も、すでに席についていた。 「まず、増えた理由を確認しましょう」 戸田がそう言うと、真帆が手を上げた。 「営業では、先月から提案書の下書きを多く作りました。でも、サポート部の問い合わせ整理も増えていたはずです」 由衣の眉が、きゅっと寄った。 「サポート部では、決められた形式で要約しています。長いコードを何度も作る開発部のほうが、使っているのではありませんか」 「こちらは、必要なときだけ呼んでいます」 蓮は静かに答えた。けれど、その声には少しだけ硬さがあった。 紬は、二人の間に置かれた請求書を見た。数字は増えている。だが、責める相手の名前は、どこにもなかった。 「蓮さん。利用ログを見せてもらえますか」 蓮はノートパソコンを開いた。OpenAIの管理画面から取り出した一覧が、壁のモニターに映った。日付。呼び出し元。モデル名。トークン量。そこまでは並んでいる。 「このログには、department_idやproject_idはありません」 蓮が指で画面をなぞった。 「department_idは部門の番号です。project_idは業務や案件の番号です。これがないと、誰が何に使ったかを結び付けられません」 「でも、モデル名はありますね」 真帆が身を乗り出した。 「はい。ただ、営業もサポートも開発も、同じモデルを使っています」 蓮がモデル名の列を開いた。そこには、似た名前が続いていた。提案書の下書きも、問い合わせの整理も、コード生成も、同じ行の中に混ざっていた。 「全社の利用量を見ても、原因は分けられません」 その言葉のあとに、短い沈黙が落ちた。 紬は、費用の計算式をホワイトボードに書いた。 入力トークン数×入力単価＋出力トークン数×出力単価。 「呼び出し回数だけでは、費用は見えないんですね」 「そうです。しかも、今のログはトークンを合計でしか持っていません。入力と出力を別々に記録していないんです」 蓮は、申し訳なさそうに画面を閉じかけた。 「出力の単価は、入力より高いことが多いです。出力は入力の3〜6倍になりやすいという説明もあります。Pepabo Tech Portalにも、処理ごとの入力・出力トークンを記録する考え方が出ています」 「つまり、長い提案書や詳しいコードを返す処理ほど、同じ一回でも費用が大きくなる」 紬が言うと、蓮はうなずいた。 「その可能性があります。でも、どの仕事の出力が膨らんだのかは、今の記録では追えません」 蓮は、昨日の処理を時間順に並べた。営業が使った時間。サポートが使った時間。開発が使った時間。ところが、同じ時刻に複数の処理が走っている。呼び出し元は共有のシステム名だけだった。 「この時間帯は、サポート部の自動整理です」 由衣が画面を指した。 「その直後に、営業の提案書作成もあります」 真帆が答えた。 「では、増加分はどちらですか」 戸田の問いに、誰もすぐには答えられなかった。 さらに、蓮が別のログを開いた。そこには、ストリーミング表示を使った処理があった。回答を少しずつ画面へ流す仕組みだ。 「ここにも、失敗があります」 蓮の指が止まった。 「回答の途中で届くチャンクだけを保存していました。最後のチャンクにusage情報が入る仕様なのに、そこを保存していません」 「usage情報には、トークン量が入っているのですか」 「はい。だから、この処理は正確な入力と出力の量が分かりません。画面には回答が残っています。でも、請求につながる記録が欠けています」 由衣が小さく息を吐いた。 「使ったことは分かるのに、いくら使ったかは分からない」 紬は、その言葉を聞いて、鉛筆を握り直した。費用が増えたことだけなら、節約の方法を考えられる。軽いモデルに変えることもできる。回答を短くすることもできる。 けれど今は、誰も説明できない。 営業はサポートを疑う。サポートは開発を疑う。開発は自分たちの利用量を示せない。費用の行き先が見えないままでは、成果も判断できなかった。 そのとき、戸田の携帯電話が震えた。経営企画からの連絡だった。戸田は画面を読み、ゆっくり顔を上げた。 「次の予算会議までに、業務別の費用を見えるようにしてほしいそうです」 誰も言葉を返さなかった。窓の外では、朝の雲が工場の屋根を白く照らしている。 紬は新しいページを開いた。そこに、部門。業務。プロジェクト。モデル。入力トークン。出力トークン。利用日。呼び出しステップ、と書いた。 最後に、まだ空いている欄へ、ゆっくり記した。 「誰の、何の仕事か」 蓮がその文字を見た。 「次は、ログに名前を付けます」 紬はうなずいた。請求書の数字は、まだ冷たいままだった。だが、その横に並ぶべき言葉が、少しずつ見え始めていた。

翌朝、蓮は小さなノートパソコンを抱えて、紬の席を訪ねた。画面には、生成AIの呼び出しを部門や案件ごとに追跡する、新しい記録の形が映っていた。 「紬さん、少し時間をもらえますか」 「もちろんです。昨日の請求書のことですね」 蓮はうなずいた。窓の外では、工場の屋根に朝の光がのびていた。 「SIOS Tech Labの部門別追跡・可視化の事例を調べました。そこでは、APIを呼び出すたびに、仕事の情報を一緒に記録していました」 「仕事の情報、ですか？」 「はい。誰が使ったかを、あとから勘で探すのではありません。呼び出す瞬間に、札を付けておくんです」 蓮が画面を少し傾けた。白い画面に、三つの名前が並んでいた。

department_id：どの部門か
project_id：どの案件・プロジェクトか
event_id：どの処理やイベントか

「たとえば、営業部が新製品の提案書を作るなら、department_idは営業部です。project_idは新製品の提案。event_idは、提案文の下書き作成になります」 「なるほど。三つの札で、その呼び出しが何の仕事か分かるんですね」 「そうです。難しく聞こえますが、APIに仕事の札を付けてから呼び出すだけです」 紬は、昨日の請求書を思い出した。そこには全社の合計しかなかった。後から数字を見つめても、営業の提案書なのか、サポートの問い合わせ整理なのかは分からない。 「つまり、請求書を見てから部門を推測するのではなく、使った時点で部門へ結び付けるのですね」 「その通りです」 蓮は、古いログの箱から一枚の紙を取り出した。そこには、呼び出し時刻と成功・失敗だけが記されていた。誰の仕事かを示す札は、どこにもない。 「このログは、呼んだ事実は教えてくれます。でも、仕事の名前がありません。だから、費用が増えた理由を説明できませんでした」 紬は紙の端をそっとなでた。 「三つの札があれば、この箱の中身も変わりますね」 「はい。さらに、使った量も分けて残します」 蓮は次の画面を開いた。表には、部門、案件、イベント、モデル、入力トークン数、出力トークン数、利用日が並んでいた。 「トークンは、AIが文章を数える小さな単位です。入力と出力を一つにせず、別々に保存します。入力は、こちらから送った文章。出力は、AIから返ってきた文章です」 紬はホワイトボードに大きく書いた。

入力トークン数×入力単価＋出力トークン数×出力単価

「この式で、呼び出しごとの費用を出します。モデルが違えば単価も違うので、使ったモデルも必要です」 「呼び出し回数だけでは足りないのですね」 「ええ。同じ一回でも、長い文章を送り、長い答えを返せば費用は変わります。だから、入力と出力を分けるんです」 紬は、ホワイトボードの式を見つめた。昨日まで、請求額は大きな一つの塊だった。今は、小さな仕事ごとの箱に分けられる気がした。 「OpenAIを営業部、Anthropicをサポート部、GoogleのAPIを開発部、というように分ける方法もありますか？」 「できます。ベンダーごとに、プロジェクトやワークスペースを分ける方法があります。ただ、同じ部門が複数のモデルを使うこともあります」 蓮は画面を切り替えた。 「ですから、鍵を一つだけにするのではなく、業務やプロジェクトに近い単位で分けます。参考にした生成AI APIコスト管理の記事にも、部門配賦のためにAPIキーやプロジェクトを分ける考え方が出ていました」 「でも、共通の検索基盤や監視の処理は、特定の部門だけの仕事ではありません」 紬がそう言うと、蓮はうれしそうに笑った。 「そこが大切です。業務に直接ひも付く利用は、担当部門へ配賦します。でも、全社で使う共通基盤は共通費にします。無理にどこかの部門へ押し付けません」 「実際の使い道に合わせて分けるのですね」 「はい。費用を責めるためではありません。どの仕事で、どんな使い方をしているかを知るためです」 その言葉が、紬の胸に静かに落ちた。 「高いモデルを使った部門を探して、注意するためだと思っていました」 「高いモデルを使ったから、悪いとは限りません。判断が難しい提案なら、高いモデルが役に立つかもしれない。定型的な整理なら、軽いモデルで十分かもしれない。仕事の内容に合ったモデルを選べているかを見るんです」 蓮は、画面に二つの流れを描いた。 「まず、呼び出す前に三つの札を付けます。次に、呼び出し結果から入力トークン数と出力トークン数を受け取ります。モデルの単価を掛けて、費用を記録します。月末には、部門、案件、業務ごとに集計します」 「古いログを見て悩む時間が、呼び出した時の記録に変わる……」 「そうです。記録があれば、増えた理由も、減らせる場所も見えてきます」 紬は引き出しから新しい付箋を出した。そこへ、ゆっくり三つの言葉を書いた。 「営業提案。サポート整理。開発支援」 そして、その下に小さく書き足した。 「共通基盤」 「蓮さん。まずは営業提案の下書きから、札を付けてみませんか」 「やってみましょう。小さく始めて、実際のログを見ながら整えればいいです」 紬は、昨日の請求書を閉じた。冷たく見えた総額の向こうに、働く人の手と、助かった時間がある。その姿を知るために、三つの札が必要なのだ。 会議室へ向かう蓮の背中を見送り、紬は新しい記録表を開いた。最初の行に、部門の名前を入力した。

開発部と経理部は、すべての生成AI API呼び出しを一つの受付に通す試験を始めた。初日の集計画面で、営業部から呼んだ処理だけproject_idが空欄になり、紬は赤い付箋を画面に貼った。 「入口を一つにするって、どういうことですか」 紬がたずねると、蓮はホワイトボードに細い箱を描いた。 「APIを包む小さな受付部品です。これをラッパーと呼びます。画面やバッチが直接APIを呼ばず、必ずこの受付を通ります」 蓮は箱の左に、三つの札を書いた。 department_id。どの部門か。 project_id。どの仕事のまとまりか。 event_id。どの一回の業務か。 「呼び出す前に、この三つを受け取ります。呼び出した後は、使った量と費用を記録します」 二人は手順を紙に書いた。まず、画面や処理が三つのIDをまとめる。次に、ラッパーへ渡す。ラッパーはその情報を持ったまま、OpenAI APIを呼ぶ。返事を受け取ったら、利用量を読み、ログ保存へ渡す。 「一つでも抜けたら、すぐ分かるようにしましょう」 紬は保存する項目を読み上げた。呼び出し時刻。モデル名。department_id、project_id、event_id。prompt_tokensとcompletion_tokens。APIが返すusage。そして、入力と出力の単価から計算された費用。 「usageは、使った量の明細です。呼び出し回数だけではなく、入力と出力のトークンを残します」 「同じ仕事でも、長い回答なら出力が増えますからね」 「そうです。だから、あとで計算し直せます」 蓮は、参考にしていた生成AI APIコスト管理の構成を開いた。Google Apps ScriptとGoogle Sheetsを使い、月次の費用を集める方法も紹介されていた。 二人はまず、営業部の提案書作成だけを試した。紬はテスト用の案件を選び、蓮はログ画面を開いた。営業担当が文章の整理ボタンを押す。受付を通り、APIが返事をする。数秒後、集計表に一行が増えた。 しかし、project_idの欄は空白だった。 「department_idは入っています。event_idもあります。でも、仕事の札だけありません」 蓮は処理の道を一本ずつたどった。画面から直接呼ぶ経路では、案件番号を画面の入力から作っていた。ところが、バックグラウンド処理へ回す経路では、古い形式のジョブを使っていた。画面の経路はproject_idを渡さず、背景の経路だけが別の場所から拾っていた。 「二つの道で、持っている荷物が違いますね」 紬の言葉に、蓮はうなずいた。 「受付で補えばよいと思っていました。でも、受付の中で推測すると、別の仕事へ費用を付ける危険があります」 二人は設計を変えた。画面で作ったIDを、バックグラウンド処理の荷物にもそのまま入れる。再試行するときも、複数段階の処理へ進むときも、同じ業務情報を引き継ぐ。ラッパーは受け取った値を勝手に書き換えない。 IDがない呼び出しは、エラーとして消さなかった。未配賦という場所へ別に記録することにした。 「空欄を無理に営業部へ押し込むより、分からない費用として残すほうが正直です」 紬は、未配賦の行に灰色の印を付けた。あとで持ち主が分かったら、根拠を残して付け替える。分からないままなら、分からないまま見えるようにする。 次の試験では、ストリーミング処理でつまずいた。返事が少しずつ届く方式だった。途中のチャンクには文章が入っている。だが、usageは入っていない。蓮の処理は最初の返事を保存していたため、費用が空欄になった。 「文章は届いているのに、利用量だけがありません」 蓮はログを拡大した。最後のチャンクに、usageが含まれていた。そこで、途中の文章は画面へ流し、費用の記録は最後のチャンクを受け取ってから行うように直した。 「最後まで待ってから、usageを確認するんですね」 「はい。最後の返事を見ずに、費用を決めないようにします」 再試行のテストも行った。最初の呼び出しが一時的に失敗し、同じ提案書の処理がもう一度走る。ログには二行が残ったが、どちらも同じdepartment_id、project_id、event_idを持っていた。蓮は呼び出しごとの費用を残し、集計では同じイベントの合計として見られるようにした。 最後に、蓮はログを集計画面へ送った。Google Sheetsの「月次集計」シートには、Google Apps Scriptの時間ベーストリガーで定期的に行が追加される。APIキーはコードに書かず、PropertiesServiceに保存した。 画面の切り替えボタンを押すと、部門別、プロジェクト別、イベント別に費用の表示が変わった。未配賦だけを選ぶこともできる。 ただし、プロンプト本文は一覧に出さなかった。費用管理に必要なID、モデル名、トークン数、usage、費用だけを集計する。原文が必要なときは、権限を持つ担当者だけが別の保管場所で確認する。 夕方、営業部のproject_idが入った行が、集計画面の上から静かに流れた。紬は赤い付箋をはがし、空欄ではなく「未配賦」と表示された行を見つめた。 「見えない費用に、札が付きましたね」 蓮は、白い画面に増えた小さな色分けを見て笑った。 「これで、どの仕事がAPIを使ったのか、仕事の道筋から追えます」

予算会議の日、紬は大きなモニターに、部門別の生成AI API費用ダッシュボードを映した。画面には、青葉製作所の仕事が、色のついた小さな箱に分かれて並んでいた。 窓から冬の光が差していた。前の会議では、白い画面に全社合計だけが表示されていた。数字は大きかった。けれど、どこから来たのかは分からなかった。 「今日は、費用の大きさだけではなく、使い方まで見えます」 紬がそう言うと、役員席から椅子の動く音がした。 画面の左には営業部。中央にはサポート部。右には開発部。部門ごとに、業務名、モデル名、入力トークン、出力トークン、利用日、費用が並んでいる。 「この色は、業務のまとまりです」 蓮がモニターの端を指した。 「APIラッパーが、呼び出しのたびに業務IDを付けています。だから、同じ部門の中でも、仕事ごとに分けて見られます」 「請求書を、仕事の棚に戻したようですね」 経理部長が、ゆっくりとうなずいた。 紬はサポート部の色を大きくした。問い合わせ整理の行では、入力よりも出力の欄が目立っている。要約文が長く、費用もその分だけ増えていた。 出力は入力の3〜6倍になりやすいという傾向が、AI経営総合研究所の解説にも示されている。紬は、その傾向を思い出しながら、赤い行を見つめた。 「サポートでは、答えを作る前の整理に、長い文章を出していました」 サポート部の課長が、眉を寄せた。 「要約なら、必要な項目だけで足りるかもしれません。長さを決めて、結果を見直します」 以前は、サポート部に費用の話をしても、全社の請求額しか渡せなかった。今は、どの処理で出力が膨らんだのかを、担当者が自分の目で確認できる。 次に、蓮が開発部の画面を開いた。紫色の行が、細い線のように何本も重なっている。 「こちらはコード生成です。試しながら書き直す処理と、本番前のレビュー処理を分けました」 画面の業務欄には、別々のproject_idが表示されていた。 「同じ開発部でも、試行錯誤と本番確認では、必要な精度が違います」 蓮は、静かに続けた。 「精度が必要なレビューには高性能なモデルを使います。短い下書きなら、軽いモデルを試せます」 モデルは、ただ高性能ならよいわけではない。仕事に必要な精度と、出力の長さを見て選ぶ。蓮の説明を聞くうちに、開発部長の表情から、費用を隠したいときの硬さが消えていった。 営業部の画面には、提案書作成という一つの業務が表示されていた。その中には、顧客情報の整理、構成案の作成、文章の下書き、確認という工程が並んでいる。 「営業部は、利用量が多いだけではありません」 紬が言った。 「どの工程で使っているかが分かります。構成案に使うのか、文章の下書きに使うのか。それぞれの価値を、現場と話せます」 営業部長は、緑色の行を見比べた。 「下書きは助かっています。けれど、顧客情報の整理は、別の方法でもよさそうです」 会議室の空気が、少しずつ変わった。 費用が増えた部門を探す会議ではなくなっていた。費用が増えた原因と、費用をかける価値がある業務を、分けて話せる会議になっていた。 紬は資料の最後に、参考事例を一つ載せていた。popbitsの「バックオフィスAI化」事例では、対応工数を半減したと紹介されている（出典：popbits「バックオフィスAI化」事例）。それは青葉製作所の成果ではない。けれど、業務を分けて見れば、改善する場所を選べる。その考え方を伝えるには、静かな実例だった。 役員が、画面の下にある小さな欄を見つけた。 「未配賦は、まだ残っていますね」 「はい。業務IDを付けられなかった呼び出しです」 紬はうなずいた。 「ここをゼロに近づけることも、運用の仕事です。請求書を見てから探すのではなく、使った時点で記録します」 蓮が、手元のメモを閉じた。 「各部門に、自分たちの画面を渡せます。モデルや出力の長さを変えた結果も、次の月に比べられます」 経理部長は、分厚い請求書を机の端へ移した。そこには、もう赤い付箋が貼られていない。 会議の終わりに、営業部、サポート部、開発部の担当者が、それぞれの画面を保存した。紬だけが費用を抱えるのではない。使った部門が、自分たちの仕事と費用を見に行く流れが生まれた。 モニターを消すと、会議室は少し暗くなった。それでも、前の月のような冷たさはなかった。色分けされた箱の中に、誰かの仕事の姿が戻っていた。

次の月末の夕方、紬はふたたび、誰もいない会議室で新しい請求データを開いた。窓の外は、前の月と同じように青く暮れ始めていた。 けれど、画面はもう違っていた。 上には全社合計があった。その下には、部門、プロジェクト、業務の名前が順に並んでいる。OpenAI API、Anthropic、Google Gemini APIから集めた記録も、同じ画面で見られた。 営業部。新規提案。提案書の下書き。 サポート部。問い合わせ対応。回答の整理。 開発部。製品改修。コードの説明。 それぞれの行には、入力トークンと出力トークンも記録されていた。送った文と、返ってきた文。その量が分かれると、費用の動きも静かに見えてきた。 「前は、合計額だけでしたね」 紬がつぶやくと、隣の席に来た蓮が画面をのぞいた。 「今は、呼び出しの行に仕事の名前があります。何に使った費用か、たどれます」 数日後、サポート部では問い合わせ対応のログが開かれていた。担当者は、画面の左にAIが作った回答の下書きを置き、右に自分が確認して直した最終回答を並べていた。 「この処理は、回答を考えるところまでです」 「送信する前の確認は、私たちがします」 担当者の指が、二つの記録を分けていく。下書きの費用と、確認にかかった時間が、同じ問い合わせの流れとして残った。 開発部では、蓮が新しい処理を登録していた。入力欄には、いつものコードのほかに、department_idとproject_idがある。 「ここは開発部の札。こちらは製品改修の札です」 蓮はそう言って、迷わず二つを選んだ。APIを呼ぶ前に札を付ける。それが、もう特別な作業ではなくなっていた。 営業部の担当者も、昼休みにダッシュボードを開いていた。提案書の下書きに使った費用を見て、似た文章を何度も作る処理を止めた。必要な処理だけを残し、長い回答が必要な案件と、短い定型文で足りる案件を分けていた。 「この行は残します。お客様ごとに内容が変わるので」 「こちらは前の文章を使えますね」 会話は、費用を責める声ではなかった。仕事の流れを確かめる声だった。 その月の集計を終えるころ、紬は画面の端にある「未配賦」の欄に気づいた。なくなってはいない。共通の検索処理や、登録前の試験呼び出しが、まだいくつか残っていた。 紬は担当者へ短いメッセージを送った。 「この処理の業務名を確認させてください。分かる範囲で大丈夫です」 すぐに答えが返らなくても、紬は欄を消さなかった。空白のままにせず、次に確認する場所として残した。 請求データを確認する時間に、各部門の人が自然に加わるようになった。経理だけが費用に名前を付けるのではない。AIを使った人が、自分の仕事に札を戻していく。 紬は集計データを保存した。画面を閉じると、机の上に古いメモが残った。 「誰の、何の仕事か」 最初の月末に、鉛筆で書いた言葉だった。紬はその紙を折らず、ファイルの横にそっと置いた。 翌朝、始業のチャイムが鳴った。 サポート部で新しい問い合わせが開かれる。開発部で処理の登録画面が立ち上がる。営業部で提案書の下書きが始まる。 APIが呼び出されるたび、部門の札が付く。プロジェクトの札が付く。業務の札が付く。 青葉製作所の画面には、金額だけでなく、誰かの仕事の名前が並んでいた。窓から入る朝の光が、紬の机の小さなメモを静かに照らしていた。