経理AIエージェント開発のプロジェクト立ち上げから関わったインターン生の話

TOKIUMでエンジニアとして長期インターンシップをしている、立命館大学大学院修士1年の岩崎(@ABfry)です！ 今年の5月初旬から経理AIエージェント開発のプロジェクトにアサインされ、現在「TOKIUM AI出張手配」の開発に取り組んでいます。 この記事では、私がこのプロジェクトに参加した背景や、実際にどのような業務を行ったのかご紹介しようと思います。

そもそも、AIエージェントって何？

AIエージェントとは

AIエージェントとは、環境を認識し、意思決定を行い、特定の目標を達成するために自律的に行動できるソフトウェアシステムです。従来のChatGPTのような対話型AIが人間の指示を待って応答するのに対して、AIエージェントは最小限の人間の監督で計画を立て、推論し、行動を起こすことができます。

Microsoftは、エージェント型AIを「最小限の人間の監督でタスクを完了するために計画、推論、行動する自律的なAIシステム」と定義しています。この自律性こそが、AIエージェントの最大の特徴です。

AIエージェントの5つの特性

1. 自律性（Autonomy）: 割り当てられたタスク以上のことを実行でき、人間の監督を大幅に削減
2. 推論能力（Reasoning）: 文脈的な手がかりや高度な意思決定により、独自に解決策を選択
3. 適応的計画（Adaptable planning）: 条件が変化したときに計画を変更可能
4. 文脈理解（Context understanding）: 人間の言語を容易に理解
5. 行動実行（Action enabled）: 自身が能力があると判断したときに具体的な解決策を提供

少しややこしく感じるかもしれませんが、要するにAIエージェントは、「人間の指示を待って応答するのではなく、自分で考えて行動するAI」という認識で大丈夫です。

TOKIUMにおけるAIエージェント

TOKIUMでは、「経理業務の自動運転」を目指して、経理AIエージェントの開発に取り組んでいます。2025年5月に「TOKIUM AI出張手配」をその第1弾として発表しました。

TOKIUM、業務の自動運転を支援する 「経理AIエージェント」の提供を発表｜ニュース｜株式会社TOKIUM（トキウム）

なぜ出張手配エージェントから始めたのか

調査*によると、62.7％のビジネスパーソンが交通手段や宿泊先の比較・検討といった出張手配業務が営業活動に影響を与えていると回答しています。

従来の出張手配には、以下のような課題がありました：

• 複数の予約サイトを行き来する煩雑さ
• 社内規程の確認と遵守の手間
• 事前申請書の作成と承認プロセス
• 急な出張への対応の難しさ

これらの課題を解決し、ビジネスパーソンをルーティンワークから解放するために、AIエージェントの自律的な処理能力に着目しました。

*株式会社TOKIUMが2025年6月に営業担当者1,100名を対象に行った、出張手配に関する実態調査

ハッカソン感覚で始まったプロジェクト

プロジェクトへの参加経緯

私は2024年の1月からTOKIUMで長期インターンシップをしており、当時はPF戦略室という新規事業などを検討する部署に所属していました。主にTOKIUM契約管理の開発に携わっており、この事業がだいぶ軌道に乗ってきた頃でした。

そんな中、次の事業として経理AIエージェント開発に取り組むという話が持ち上がりました。私は個人的にAI開発に興味があり、MCPなど様々なツールを触っていたこともあって、上長から「このプロジェクトに参加してみないか」と声をかけていただきました。

ゼロからのスタート

2025年の5月上旬、私は上長、開発部の部長、CTOの4人でモック開発を行いました。まさにゼロからの状態で、「チャットで話しかけるだけで出張の手配が全部できたら面白いんじゃない？」というアイデアから始まりました。

この期間は本当にハッカソンのような雰囲気で、毎日の定例では、その日の進捗報告や翌日の作業内容のすり合わせを行いました。また、作業通話をしながらリアルタイムで意見交換なども行っていました。「この実装どう思う？」「こんなエラーが出てるんだけど」といった会話が飛び交い、まるで同じ部屋で開発しているような一体感がありました。

初期の試行錯誤

業務フローの理解から始める

最初に取り組んだのは、出張における「事前申請」の自動化でした。まずは「申請書の作成」を自動化することから始めました。しかし、技術的な実装に入る前に、私たちは現実の業務フローを深く理解する必要がありました。

そこで、実際に出張手配業務を行っている秘書の方に基本的な申請の流れの確認を行いました。「具体的にどのような手順で申請を行うか」「どのような情報が必要か」「どんな確認事項があるか」など、細かい業務の流れを聞き取り、それをもとに詳細な業務フローチャートを作成しました。

地味な作業に見えますが、AIエージェントの構築は、「人間の作業を自動化する」という観点から、「人間の作業を理解する」という作業が必要です。 ここで作成した業務フローは、後のAIエージェント開発において非常に重要な基礎となりました。

プロトタイプの開発

業務フローの理解が深まったところで、いよいよコーディングに着手しました。技術スタックの選定では、以下のような構成で開発を進めることにしました：

• AIエージェント: OpenAI Agent SDKを採用
• バックエンド: FastAPIで高速かつ型安全なAPIを構築
• フロントエンド: Next.jsでユーザーフレンドリーなチャットインターフェースを実装

ゴールデンウィーク明けの時点で、基本的な出張申請の自動作成機能が一通り動作するところまで完成しました。ユーザーが「来週月曜から大阪に2泊3日で出張したい」とチャットに入力すると、AIエージェントが必要な情報を聞き取り、TOKIUM経費精算内で事前申請を自動生成するという一連の流れまで実装できました。

この短期間での成果は、4人という少人数チームだからこそ実現できた機動力と、ハッカソン的な集中開発の賜物でした。

開発初期段階のモック

本格的なプロジェクト始動

ゴールデンウィーク明け、プロトタイプの可能性が認められ、プロジェクトは一気に本格化しました。ここで私は、学生のハッカソンや個人開発とは全く違う「プロダクト開発」の厳しさを実感することになります。

チームの急拡大と開発体制の変化

新しいメンバーの参加

プロジェクトの本格化に伴い、チームも大幅に拡大しました：

• プロダクトマネージャー（PdM）：ユーザー要求の整理と優先順位付けを担当
• 正社員エンジニア：フロント開発やバックエンド開発など、各分野のエンジニアが参加
• もう1人のインターン生：AI周りの開発を担当

4人の小さなチームから、一気に10人近いチームになりました。正直、最初は戸惑いました。これまでの「なんでも自分でやる」スタイルから、「役割分担して効率的に進める」スタイルへ変化していきました。

スクラム開発の導入

本格的なスクラム開発が始まり、以下のような新しい習慣が生まれました：

• デイリースクラム（朝会）：毎朝15~30分、昨日やったこと・今日やること・困っていることを共有
• スプリントプランニング・レビュー、レトロスペクティブ：毎週、次のスプリントで何を作るか計画、レビュー、振り返り(KPT)を行う

「動けばいい」から「価値を生み出す」への転換

正直に言うと、最初は「動くものが作れた！」という達成感に浸っていました。しかし、実際のビジネスで使うプロダクトを作るということは、単に技術的に動作するだけでは不十分だということを改めて痛感しました。

インターンとして参加している私にとって、以下のような点が特に学びになりました：

1. フィードバックの重要性

プロトタイプを社内の方に使ってもらうと、想像もしていなかったフィードバックが次々と返ってきました。「こういう機能がほしい」「お土産の情報など、出張手配だけにとどまらず色んなことをしたい」といったようなエンジニア視点では気づかない課題・要望が山のようにありました。 利用者目線でのフィードバックはサービスの品質を高めるために必要不可欠なものであると改めて実感しました。

2. 品質への責任

学生レベルでの開発では「バグがあっても後で直せばいい」という考えになりがちですが、実際のプロダクトではそうはいきません。ユーザーの業務に直接影響するため、一つ一つの機能に対して責任を持つ必要がありました。また、出張手配というサービスであるため、提供される情報の精度も重要です。

AIエージェントならではの「難しさ」

技術的な詳細は正社員の方が別のブログで詳しく書かれると思うので、ここではインターンの私が感じた「開発の難しさ」を中心に書きたいと思います。

ベストプラクティスがない世界での開発

一番苦労したのは、AIエージェント開発のベストプラクティスがまだ確立されていないことでした。例えばWebアプリケーションなら「こういう時はこうしたほうが良い」という定石のようなものがいくつかありますが、AIエージェントの世界ではすべてが手探りです。

• プロンプトの書き方一つとっても正解がない(出張手配というサービスにおいて)
• AIエージェント間の役割分担をどうするか
• ユーザーとの対話をどこまで自動化するか
• AIの判断にどこまで任せるか

毎日がトライアンドエラーの連続で、「これでいいのかな？」と不安になることも多かったです。チームで議論を重ね、実際に動かしてみて、ダメだったらまた作り直す。この繰り返しでした。

フルタイムエンジニアとの情報格差

正直、一番大変だったのは、フルタイムで働く正社員の方々についていくことでした。前述のベストプラクティスがない状態というのも相まり、PDCAのサイクルが非常に早く、フルタイム勤務ではないインターンの私にとって、情報のキャッチアップは常に課題でした。

• 月曜日に出社したら、金曜日とは違うアーキテクチャになっていた
• Slackの未読が数十件溜まっていて、重要な決定事項を見逃す

でも、チームの皆さんは本当に優しくて、分からないことがあれば丁寧に教えてくれました。Notionなどのドキュメントにまとめられていたり、朝回のタイミングで丁寧に変更点を教えてくださったことは、非常にありがたかったです。

AIエージェントの「賢さ」と「使いやすさ」のバランス

最初は「AIが賢ければ賢いほど良い」と思っていましたが、実際はそうではありませんでした。例えば、ユーザーが「大阪に行きたい」と言ったときに、AIが「大阪のどちらへ？梅田？難波？それとも大阪城周辺ですか？」と細かく聞き返すと、かえってユーザーは面倒に感じてしまいます。

そこで、「ちょうどいいスマートさ」を目指しました。出張日や場所など、必要最低限の情報を最初にユーザーから引き出し、交通手段などの細かい要望は、特に指示が無ければ内部で推論してユーザーの負担を減らすといった方針です。例えば「大阪出張」と言われたら、まずは日程だけを確認し、宿泊先は一般的なビジネスホテルを自動で選ぶなど、ユーザーの入力を最小限に抑える工夫を行いました。

プロダクトマネージャーとの協業

エンジニアとして「技術的に可能なこと」と、プロダクトとして「やるべきこと」は違うということを学びました。毎週のプロダクトミーティングでは、機能の優先順位付けや、ユーザーストーリーの検討など、技術以外の視点でプロダクトを考える機会がありました。

このような「難しさ」がある中でも、最先端のAI開発に携われること、しっかりとしたスクラム開発のプロセスに参加できること、そして実際のユーザーからのフィードバックを受けながら責任あるプロダクト開発ができる環境は、学生レベルではなかなか得ることができない貴重な経験です。技術的な挑戦と同時に、様々な面で成長できたと感じています。

おわりに

経理AIエージェントの開発は、単なる技術的な挑戦以上の意味を持っています。それは、人間の仕事をより創造的で価値の高いものに変える可能性を秘めています。

TOKIUMでのインターンシップを通じて、私は最先端のAI技術に触れるだけでなく、それを実際のビジネス課題解決に応用する貴重な経験を得ることができました。出張手配という誰もが経験する煩わしい業務を、経理AIエージェントによって「ストレスフリー」に変えることができたのは、大きな達成感があります。

もし経理AIエージェント開発に興味がある学生の方、ぜひTOKIUMでインターンシップをしてみてください。一緒に「経理業務の自動運転」を実現しましょう！