社内のバックオフィスから相談が来ました。マネーフォワードクラウドとKing of Time（勤怠管理）、それに社内で使っているAIチャットをつなげられないか、と。勤務時間が急に増減している人の自動検知、経費や債務支払の異常値検知、請求書の未入金検知。やりたいことはいくつか挙がっていましたが、条件が1つついていました。身内の話だから、全部無料でやる、です。
会計・請求書・経費・給与・債務支払・人事管理・マイナンバー・年末調整・契約。この会社がマネーフォワードで使っているサービスは9つありました。これを全部つなぐとなると、それなりの開発になりそうに見えます。実際には、やりたいことに必要なサービスだけを選んでつなぎ、開発した部分もごく一部で済みました（マイナンバーのように、法令上そもそもつなぐべきでないものは最初から外しています）。
会計だけにあった公式の窓口
マネーフォワード側を調べていくと、AIチャットから直接呼び出せる公式の窓口（MCPと呼ばれる仕組みで、AIが人間の代わりにアプリの機能を直接呼び出せる接続口のことです）が用意されているのは、9サービスのうち会計だけでした。ここは公式の設定を登録するだけで、すぐにつながりました。事業者の情報や会計期間も、実際にチャットから読めています。
残り8サービスには、この手の公式窓口がありません。ここで「じゃあ諦めよう」となりそうなものですが、調べを進めると別の話が見えてきました。AI向けの窓口はなくても、開発者向けの窓口（アプリを登録すれば誰でも無料で使える、ふつうのAPI連携の仕組みです）はちゃんと公開されている。しかも経費・債務支払・給与・人事管理は、この開発者向け窓口を使えば実際にデータが取れることが、権限の一覧を洗い出して確認できました。
つまり要るのは、AIチャットとこの開発者向け窓口の間に立つ、小さな橋渡し役です。1つ作れば、あとは接続先を変えるだけで経費にも債務支払にも使い回せます。ゼロから9個作る話ではありませんでした。
会社単位ではなく、サービスごとの権限
つないでいく過程で一番手間取ったのは、実は技術ではありませんでした。マネーフォワードの権限は、会社全体の管理者権限を持っていても、各サービスの中には自動で入れません。経費なら経費、債務支払なら債務支払で、それぞれ別に招待を受けて許可を取る必要があります。
ここでちょっとした行き違いも起きました。招待メールが会社のアドレスに届いていたのに、ふだんその会社アドレスではマネーフォワードを使っていなかったので、個人のGmail側で見ると事業者の一覧が空っぽに見える。権限が足りないのかと思ってブラウザで確認していったら、単に別のサービスのタブに古いログイン状態が残っていただけでした。招待自体は正しく届いていて、入り直したらあっさり解決しています。技術的な壁より、誰がどの権限を持っていて、どのメールアドレスで動いているかを一つずつ突き合わせる作業のほうが時間を食いました。
AIにどう頼んだか
私はコードを自分で書かず、AIに頼んで作ってもらっています。このときも、やりたいことをそのまま日本語で渡しました。
会計はマネーフォワード公式のAI連携がもう用意されているから、そのまま使う。
経費と債務支払と給与・人事管理には公式のAI連携がないから、代わりに社内チャットとマネーフォワードの間に立つ小さな橋渡し役を作って。
認証は、使う人それぞれのマネーフォワードの権限で通して。管理者の権限をまとめて共有する形にはしないで。私自身は中身を見られなくていい。必要な人だけ見えれば十分。
つながったら、まず経費の一覧を実際に取ってこられるか試して。
管理者の権限を共有しないというのは、単なる好みではありません。誰かのチャットでのやり取りが、その人の持っている範囲を超えて社内の他部署のデータまで見えてしまうのを避けるための線引きです。ここは最初に決めておかないと、あとから絞るのが面倒になります。
毎回のサインインが面倒という声
経費、債務支払、給与・人事管理と1つずつつないでいくと、使う側からすると「開くたびに何回もサインインを求められて面倒」という話になりました。もっともです。そこで4つの窓口を、チャット側から見える入口としては1つにまとめ直しました。最初に許可を出すときだけはサービスごとの画面を順に通りますが、ふだん使うときに入口を選び分ける手間はなくなります。会計だけは公式の仕組みなので技術上ここには混ぜられず、別枠のままです。
途中、ドキュメントだけでは分からないことも何度か出ています。給与のデータを取るAPIには決まったヘッダー情報が必須で、これは実際に叩いてエラーを読むまで気づけませんでした。従業員の一覧も、本来の人事側の窓口では権限がなくて使えず、給与側の窓口からなら同じ情報が取れることが、試行錯誤の末に分かっています。書類の対応表と実際の挙動がずれる場面は、思っていたより多かったです。
余談ですが、給与や人事管理はバックオフィスの担当者に「連携は難しそうです」と最初に伝えていました。あとで調べ直したら、実際にはつながりました。伝えていたことを訂正する一言を添えて、正直に案内し直しています。
唯一、無料の外に出た窓口
King of Timeも打刻や勤怠のAPI自体は公開されています。ただし利用するには、アクセス元のグローバルIPアドレスをあらかじめ登録しておく必要がありました。クラウド上の従量課金の実行環境から呼ぼうとすると、送信元のIPは基本的に固定されていません。固定するには専用の仕組みを別途足す必要があり、月々数千円のコストが乗ります。
無料でやる、という条件からすると、ここだけは素直に「無料の外」でした。だから今回は一旦保留にして、コストの出ないマネーフォワード側から先に手をつけています。全部を無理に無料へ押し込むより、コストが出る所は出ると認めて、そこだけ後回しにする方が結局早いです。
開発力より、権限を持つ人
今回分かったのは、使っているサービスの数だけ開発が要るわけではない、ということです。各サービスがふつうに公開している開発者向けの窓口があれば、そこに小さな橋渡し役を1つ置くだけで、あとは接続先を変えて使い回せます。無料で登録できることがほとんどですし、動かす場所も今あるサーバーに相乗りできれば追加費用は出ません。
一方で、時間を取られるのは技術より人です。どのサービスで誰が管理者権限を持っているか、招待はどのメールアドレスに送っているか。ここが曖昧なまま進めると、つながらない原因が権限なのか設定ミスなのか切り分けられなくなります。そしてもう1つ、King of Timeのようにアクセス元のネットワークまで縛ってくる窓口だけは、無料の前提が崩れます。ここは調べる前から諦める必要はなく、調べた上で「ここはコストが出る」と分かってから止めればいい話です。