株式会社LOWWS CTOのスラヴィ・パンタレーブ(Slavi Pantaleev)にインタビューし、 現在携わっているプロジェクトの中で興味深い技術や最新の知見について聞いていくコーナーです。
今回は経費管理システムにおけるAIの活用、特にOpenAIのAIモデルの優位性とUXの重要性について聞きました。
This is an interview with Slavi Pantaleev, CTO of LOWWS Inc., where we explore interesting technologies and the latest insights from his current projects.
This time, we discussed the application of AI in expense management systems, particularly the advantages of OpenAI and the importance of user experience (UX).
The English article follows the Japanese article.
OpenAIの優位性
ナオト：今回の経費管理システムはAIシステムの使い方として、とても良いユースケースですね。このシステムはAIモデルそのものよりもユーザー体験（UX）を大事にしていると感じました。たとえば、プロンプトを正確に編集できたり、AIが正しく動いているかを確認できたりします。
スラヴィ：AIの操作をユーザーがコントロールできるようになっていて、それが時間の節約になりますよね。たとえば、請求書を100件手動で入力して、内容を精査するのは大変な作業です。ただし、AIの結果は確認しないといけないので、完全に自動というわけではありません。でも、少なくとも常に手動でやる必要はなくなり、仕事がかなり楽になります。入力作業に数日間かける代わりに、もっと生産的で創造的な作業に集中できます。
ナオト：あと、OpenAIのモデルが論理的な出力に強いというのは知りませんでした。
スラヴィ：そうですね、そう見えます。私もAnthropicのモデルも構造化出力ができると思っていたんですが、「こう指示してみて、うまくいくといいね」という感じで、あまり良くないと思いました。
ナオト：OpenAIのモデルには、構造化出力を検出するような仕組みがあるんでしょうか？
スラヴィ：そう思います。OpenAIはJSONスキーマを使っているようで、APIにリクエストを送ると、それがスキーマに合っているかをチェックしているはずです。もし一致しない場合は、再度モデルを呼び出すかもしれません。もしくは、不正確なデータをそのまま返す場合もあります。でも、実際にはスキーマ通りの出力が返ってくることが多いですね。エラー時にどうなるかははっきり分かりません。もしかしたら、空のレスポンスかもしれません。どちらにせよ、あらゆる事態に備える必要があります。AIのような非決定的なコード、もしくはAPIを使う場合、想定外の出力やデータの欠落には対応できるようにしておかないといけません。私たちが行っているコスト分類でも、ユーザーには見えませんが、JSONスキーマに従って応答を求めています。たとえば、各行のエントリは一度だけ分類されるべきです。もし繰り返していたら、それはバグです。存在しない行番号を返してきたら、それも問題です。また、リストに存在しない費目を返してきた場合も同様です。こういった不具合や、期待する構造化出力に合わない場合にも、システム側でチェックできるように作り込んでいます。
ナオト：画面の下の方にあるプロンプトには、IDのようなものがついていますよね？
スラヴィ：：はい。IDをAIがうまく認識できないんじゃないかと思っていましたが、実際にはちゃんと機能していますね。
ナオト：驚きですね。
スラヴィ：：分類カテゴリーも、少し分かりにくいところがあるので、顧客が再構成するかもしれません。でもこれはAIの問題ではありません。このシステムに将来的に加えたい機能としては、請求書に出てこないような費目を除外することです。たとえば「給料」などです。そういった不要な項目は削除して、必要なものには説明を追加することもできます。括弧付きの補足説明を加えるとかですね。これはシステムを改修しなくても、プロンプトの追加指示で対応できます。
ナオト：Googleのモデルは試されましたか？
スラヴィ：：いいえ。すべての国で利用できるわけではないので試していません。GoogleのAI関連のプレスリリースはMistralのものと似ていて、自画自賛はすごいんですが、実際にはプロダクトが存在しないこともあります。 米国や一部地域でしか使えないということがよくありますし、APIやライブラリの状況も不透明です。
ナオト：だから使わなかったんですね。
スラヴィ：：はい。OpenAIの方がうまくいきました。ドキュメントも完璧で、最初からすべての国で利用できます。地域制限もありませんし、公開された日から利用可能です。このプロジェクトではすでに3つのモデルを試し、PHPライブラリを改造したり、ドキュメントを読み解いたりしました。その結果、OpenAIで本番運用に耐えうるものができました。
ナオト：すごいですね。
スラヴィ：：UIの構築だけでもかなりの作業量でした。フォームやフィールドをいくつも作るのは繰り返しの作業です。 AIに指示を出せば、自動でやってくれます。バックエンドや非同期処理といった複雑な部分に集中できるようになります。このシステムにはReactコンポーネントも多くあります。仕入先の情報を確認・編集したり、新しい仕入先を追加したりといった操作ができます。費用管理用の別のコンポーネントもあり、データの整合性が重要です。AIはこれらのコンポーネントの作成に役立ちました。完全ではありませんが、初期作業を代行してくれたのは大きいです。
ナオト：システムもだいぶ進化したんですね。
スラヴィ：：はい。最初はまったく違う構成でした。AI分析もありませんでしたし、プロジェクトを進めながら何度も作り変えました。ユーザー体験の課題に気付き、最後にはAIの設定を操作できる機能も追加しました。
ナオト：AIがあってよかったですね。
スラヴィ：：AIがなければ、これほど良いシステムにはならなかったと思います。時間も限られていて、顧客の予算も無限ではありません。
AIのサポートがあったからこそ、非同期処理やAI分析といった機能も追加できました。
ナオト：でも、AIで仕事が減る人もいるかもしれませんね。
スラヴィ：それはあるかもしれません。でも今のところ、上級開発者や経験豊富な人の仕事は安全だと思います。AIがジュニア開発者のようにサポートしてくれるので、少人数でも多くのことができます。
ナオト：本当に面白いですね。
スラヴィ：実際のプロジェクトでAIを使って成果が出せるのは嬉しいことです。AIを導入したいという人は多いですが、すべてのプロジェクトに必要とは限りません。 でも、このように実際に役立つ使い方を見つけられると意味がありますね。
OpenAI’s Strengths
Naoto: This invoice OCR system is a really good use case for AI systems. I feel like this system cares more about user experience than just the AI model itself. You can edit precise prompts or check if the AI is working correctly.
Slavi: Yeah, it puts the operator in control of the AI, and it saves a lot of time. Entering 100 invoices manually and drilling into their expenses is a lot of work. You still need to check the AI’s work in case it makes mistakes, but overall, it makes the job much easier. You can focus on more productive and creative work instead of spending days entering invoices.
Naoto: I didn’t know OpenAI models are better for logical outputs.
Slavi: It seems like they are. I thought Anthropic could do structured output too, but it feels like you just give it instructions and hope for the best.
Naoto: Do you think there’s a system in OpenAI’s backend that detects structured output?
Slavi: I think so. OpenAI likely uses a JSON schema. When you send it to the API, it checks if the response matches the schema. If it doesn’t, maybe it retries or just returns bad data. But usually, it conforms. You still have to be prepared for failure cases, though. When you’re building systems involving non-deterministic agents like LLMs, you have to account for incorrect responses or missing data. Even in our cost classification, we have a schema behind the scenes. Each line entry should be classified once, and if it starts repeating or referencing nonexistent lines, that’s a problem. Same if it uses expense types that don’t exist. So, we need robustness in the system to catch all of that.
Naoto: Yeah. By the way, I noticed the prompt has some hash IDs at the bottom. I thought AI models would have trouble with those, but it seems to work well.
Slavi:Yeah, kind of surprising. Some of the categories might be confusing, though. The customer may revise them for clarity. That’s not the AI’s fault. Some extensions we can imagine are removing expense types that are never used, like salaries on invoices. We can also clarify labels, add descriptions in brackets, or include them in the prompt instructions—no system changes needed.
Naoto: Wow. Have you tested Google models?
Slavi:No, they’re not available in all countries. Google’s AI announcements are often like Mistral’s—big announcements but the product is only available in the US or select regions. I’m unsure about the current state of their APIs. It’s off-putting when you don’t know if a model even exists or if it’ll become available where you are.
Naoto: So, you decided not to try them?
Slavi: Yeah. OpenAI worked well. Documentation is great, and it’s globally available from day one. No regional restrictions. I already tried three different models for this project, modified PHP libraries, figured out documentation—OpenAI was the one that made it production-ready. Even with AI, it took multiple weeks of daily work.
Naoto: That’s a lot.
Slavi: Yeah, even just building the UI—so much repetitive work. Forms, fields, copying and renaming elements—AI helped with that. It saved time, and I focused on backend, async processing, more complex parts. The system uses many React components—viewing, editing, creating suppliers, managing expenses. AI helped with component creation, not perfectly, but it got the initial work done. I polished and optimized them.
Naoto: So, the system evolved?
Slavi:A lot. The AI analysis wasn’t even there at the start. I changed the design multiple times based on better ideas, better ways to use AI. User experience problems emerged over time, so I added more control features for the user.
Naoto: That’s a lot of iteration.
Slavi:Yeah. Without AI, this system wouldn’t be as good. I don’t have infinite time or the customer an infinite budget. Without AI, I’d have to cut features—no async processing, maybe no AI analysis at all. It would’ve been just manual input.
Naoto: So AI helped you do more?
Slavi:Exactly. It allowed me to add features and deliver a better product.
Naoto: Some people may lose jobs, though?
Slavi:Maybe, but higher-level jobs—experienced developers—are still safe for now. We can do more with less. AI is like having a junior dev helping out. Time will tell.
Naoto:Sounds really interesting.
Slavi:Yeah, it’s great to use AI on a real project where it makes a difference. A lot of people are still wondering how to use AI in their work. Sometimes you don’t need it, but it’s good to have a real use case.
この記事はインタビューをもとにAIを使用して作成されています。 This article was created using AI based on interviews.