「同じ開発の現場なのに別世界」、AIが3年間でもたらした衝撃
株式会社TOKIUMは2012年に創業し、2016年から法人向け経費精算SaaSを軸に企業の経理業務を支えてきた。2022年には社名をBearTailから現在のTOKIUMへと改称し、2025年5月にはAIと人が連携し、自律的に経理業務を実行する「経理AIエージェント」を発表。経費精算ツールのベンダーから「経理作業をまるごと代行するAIエージェント会社」への転換を鮮明にした。
TOKIUMのプロダクトビジョンは「あらゆる経理作業から人々を解放する」というものだ。「ソフトウェアだけで解決しなくてもいい。AIを使わなくてもいい。BPO（ビジネスプロセスアウトソーシング）を使ってもいい」という考え方が組織に浸透しており、手段にこだわらず、いかに顧客の業務を軽減するかが問いの中心に置かれている。
その中核を担う経理AIエージェントは、実はシステムのみで完結するサービスではない。西平氏は「AIと人力を組み合わせて、経理作業をまるごと代行できるエージェントです」と説明する。AIが得意とする定型処理は自動化しつつ、AIが苦手とする判断や例外対応は人間（プロスタッフ）が担う設計だ。一部だけ自動化しても顧客側に作業が残り、負担がかかるため、AIができないことはプロスタッフが補う。単なる効率化ではなく、作業自体を手放すアプローチで、ユーザーを拡大してきた。
2025年12月、3年間のDevHRを経て同サービスの開発チームに戻ってきたのが坂上氏だ。もともと新卒でエンジニアとして入社し、Androidアプリ開発で6年半のキャリアを積んだ後、開発組織の採用・組織開発を担っていた。
「同じ開発の現場なのに、別世界のようになっていた」という率直な言葉が物語るように、AIによるコード生成の精度と速度は坂上氏の想定を超えていた。コーディングそのものが好きだっただけに「ギリギリまでコードを手放したくない」と考えていたが、実際にAIにアウトプットさせてみると「どうやってもAIには勝てない」と確信。その瞬間から、AIエージェントのために環境を整える側──ハーネスエンジニアリングへと自然に足を踏み入れることになった。
いざ「ハーネスエンジニアリング」の実践へ──初めはコンテキストリポジトリの整備から
「ハーネスエンジニアリング」とは何か。西平氏は次のように定義する。「AIのための開発環境自体を作っていくエンジニアリングです。製品やコードベースが、AIによって継続的に改善されていくループを作ることが非常に重要となります」。
ただし、AIをただ使い続ければ速く開発できるという単純な話ではない。継続的にAIで開発を続けると、「技術的負債の蓄積」や「プロダクト仕様からの乖離」といった品質劣化が起きることが研究でも明らかになっている。この劣化を防ぐ取り組みこそがハーネスエンジニアリングの核心だ。
坂上氏のチームで実践する具体策の1つが、コンテキストリポジトリの整備だ。新規プロジェクトを始める際は、すべてのコンテキストを読み込ませることができるため、技術的な意思決定からプロジェクトの規約、コーディングのルール、要件定義、仕様まで、丁寧に明文化して整理した。取り組みの中では、OpenAIやAnthropicが公開するベストプラクティスはもちろん、IPAが公開する要件定義ガイドなど広く参考にした。
コードレビューの委任、コーディングルールの更新──TOKIUM流「ハーネスエンジニアリング」とは
坂上氏のチームはAIを組み込んだ開発を始めてから約1ヶ月で、3人のメンバーが1日10件以上のプルリクエストを継続的に出せる状態に達した。人間が手で書いていたころは多くても1日3～5件だったが、あるときは1営業日あたり10件以上、1件あたり500～1000行規模のプルリクエストを出せるようになった。
しかし、成果物の急増は新たなボトルネックを生んだ。チーム全員がレビュー作業に疲弊したのだ。「認知負荷と体力的な面で、この体制を続けていくのは難しいと感じました」と坂上氏は振り返る。
そこで取り組んだのがコードレビューのAIへの委任だ。「人間が今までの形と同じように細かくコードを読んでコメントしていく進め方は、AIのアウトプットを必要以上に絞ってしまうと感じました」と坂上氏は明かす。
実際にAIにレビューさせると人間が見落としていた指摘が上がるケースも多く、「AIにレビューさせた結果を信じて、mainブランチにマージしていくスタイルを作っていこうとしています」と坂上氏は話す。
AIによるレビューを運用し始めると、次の課題が浮かんだ。それは、同じ指摘が何度も繰り返されることである。このままでは、AIが毎回同じコメントを出し続ける非効率が生じる。そこで設計したのがコーディングルールの自動昇格だ。週2回、プルリクエストのコメントを全件洗い出し、共通する指摘があれば「このルールをコーディングルールに昇格すべきです」と自動でレコメンドするプルリクエストが開発者に届く。ルールがアップデートされることで、AIがコードを生成する時点から問題が解消された状態となる。
AIレビューへの移行が進む一方、品質をどう担保するかは現在進行形の課題である。現在検討しているのは、絞り込んだテストケースを人間がレビューするアプローチだ。タスクやシーンの切り方を工夫してテストケースの差分を見えやすくし、そこだけを人間が確認する。「チームで合意まで取れていて、仕組みはこれから作り始めるところです」と坂上氏は話す。
スクラムの運営にもAIを組み込んでいる。Slackチャンネルにはメンバーが開発したAIボットが常駐し、朝会の議事録を自動でまとめてToDoを抽出し、完了するまで繰り返しリマインドする。スプリントの振り返りではMiro上のホワイトボードからKPT（Keep・Problem・Try）の内容を読み取り、JiraのチケットへAIが変換する。開発以外のタスク運用コストも、AIが吸収していく。
メンバーで開発した議事録をまとめるAIボット（※アプリ作成者が広島出身のため広島弁）
エンジニアリングの成果を測る定量指標として採用しているのは、ソフトウェア開発の生産性を測るフレームワークであるFour Keysだ。なかでも変更リードタイムの改善を重視している。一方で、今後はAIが自動マージする比率や、1回のプロンプトでAIが実行し続ける時間の長さなど、Four Keys以外の新たな指標も活用していく考えだ。
チームごとのアプローチは一律ではない。別のチームでは、チーム人数を半分に絞りながら成果量を維持する取り組みを進めた。コードを細かく読む代わりに、インプットとアウトプットが仕様通りかを自動でレビューする仕組みに集中した結果だ。プロダクトの性質によって整備の勘所は異なり、各チームが自律的にボトルネックを見つけ解消していく姿勢がTOKIUMのハーネスエンジニアリングを支えている。
ハーネスエンジニアリングのカギは「越境できる人材」
ハーネスエンジニアリングを機能させる上で、西平氏がもう1つの核心として挙げるのが、役割を横断する「越境」の考え方だ。2025年末、開発組織のテックバリューに越境を定めた。AIによって開発速度が上がったことで「何を作るか」の重要性が増し、「つくるものを間違えると、目的地に全然たどり着けない。エンジニアもプロダクトマネージャーも、より上流の判断に関われるよう役割を変えていこうという話を組織の中でしました」と西平氏は語る。
西平氏は、「AI時代は越境できる人材のほうが多く必要になる」と話す。ただし、越境のためのスキル習得はAIによって効率化されたが、心理的なハードルを越えることができるかは個人差が残る状況だ。TOKIUMではそもそも自ら進んで越境をする人材が多かったが、近年はプロダクトマネージャーやエンジニアが商談などに同席し、顧客と直接コミュニケーションをとる機会がさらに増えている。加えて、一部のエンジニアが率先して自らサービスを売りに行く動きも出てきた。
エンジニアから人事へ、そして再びエンジニアへと職域を跨いできた坂上氏自身も、この越境を体現してきた1人だ。「エンジニアの開発の世界だけでは見えなかったことがたくさんあります。BtoBでは、営業が売って、カスタマーサクセスが運用に乗せて、初めて事業価値になります。その視点は越境を通して得られたものです」と坂上氏は述べる。
坂上氏が越境を経て得たもの（引用：「Developers Boost 2025」登壇資料）
ハーネスエンジニアリングを実践する上でエンジニアに求められるのは何か。坂上氏は「ビジネスサイドのメンバーが高い精度で理解している顧客の要望を、積極的に取りに行くことが第一に必要です」と指摘する。AIに何を指示すべきかを決めるコンテキストはビジネスの側にあり、そのためにも自ら足を伸ばしていく姿勢が前提になる。
一方で、過去にコードを書いてきた経験は無駄にならない。「AIのアウトプットに対して、その良し悪しを嗅ぎ分けられるかどうかは、開発経験の蓄積によって差が出ます」と坂上氏は話す。技術そのものへの深い知識よりも、危うさを察知するセンスとして経験が機能する。
この越境への親和性は、創業当初からTOKIUMに根付いている。学生創業だったため職能分担を知らない状態でスタートした西平氏は「開発者自身がプロダクトの要件を考え、お客様の情報を吸い上げることは当たり前だと思っていました」と振り返る。
西平氏自身はプロダクトマネジメントやBPO部門を経験し、坂上氏もエンジニアから人事へ、そして再びエンジニアへと職域を跨いできた。採用においても知識量よりも「自分で調べて考えられる」ジェネラリスト寄りの人材を重視してきた結果、越境に対する抵抗が少ない組織文化が醸成されてきた。
いまこの時期にハーネスエンジニアリングに取り組む意義について、坂上氏は「間違いなく今後の開発のスタンダードになる考え方です。そのスタンダードの先頭に、今ほぼすべてのエンジニアが立てる状態にあります」と述べる。
スマートフォンの普及がモバイルアプリ開発という職域を生んだように、今はすべての領域のエンジニアに同じことが起きている最中だ。「AIが当たり前になった世界でのエンジニアのあり方を定義する側に回れる。そこにチャレンジしてほしいし、TOKIUMでできると思っています」と坂上氏は強調した。
「越境に対して心理的ハードルが低い人たちが集まっている開発組織は珍しいと思います。チームメンバーの役割も変えながら、チャレンジしやすい環境だと感じています」と西平氏は言う。コードを書くことへの執着を手放した先に、エンジニアとしての世界が広がる。その可能性を、TOKIUMは実証し続けている。
TOKIUMで、わたしたちと共に未来へつながる時を生みだしませんか？
ハーネスエンジニアリングを実践するTOKIUMでは、エンジニアを積極採用中です。本記事でご興味を持たれた方は、採用サイトをご覧ください。
