AI機能をどう開発していくのか考える - フレクトのクラウドblog

こんにちは。エンジニアの浅見です。

今回は、社内向けに構築している「生成AIを用いた機能の開発方法論」の一部をご紹介します。私がAI部門に配属されてから3ヶ月が経ちましたが、生成AIの発展は衰えることなく、むしろ加速度的に成長しています。社内のシステム開発においても生成AI機能を組み込んだシステム開発の案件が徐々に増えてきているようです。一方でこれまでのシステム開発との根本的な性質の違いからなのか、（もちろん自分も含め）苦労している場面を見かけることもしばしばです。

そこで我々AI部門では、いかに生成AI機能をシステムに組み込むべきなのか、そしていかにその機能を開発していくのかを検討し、社内へ展開する施策を進めております。本ブログではこの「フレクトメソッド」の冒頭部分をかいつまんでご紹介いたします。

なお、本記事は執筆時点（2025年7月）での情報をもとに記載しております。

はじめに

さて、「生成AIを用いた機能」と聞いて読者の皆様は何を思い浮かべるでしょうか？ ChatGPTをはじめとした各社のサービスをご利用の方であれば、「会話形式で質問に答えてくれる機能」と言うイメージが強いのではないでしょうか？確かに、ChatGPTのようなユーザーと対話して問題解決をしてくれるAIはいかにも「AIエージェント」のように感じてしまいます。このイメージにより、いわゆるAIチャットボットのような問い合わせ対応機能を想像される方が多いのではないかと思います。しかし、「生成AIを用いた機能」はこれだけではありません。単なる問い合わせ対応の自動化だけでなく、これまで人間が無意識に行っていた状況判断や情報処理をAIに行わせることで、従来のシステムでは実現できなかった抽象度の高い業務を担わせることが可能です。一般的な対話型AIのイメージを抜け出して、生成AIの強みを最大限活かしたシステム開発を行うためには、生成AIの仕組みを理解した上での方法論構築が不可欠でしょう。

そこでこの方法論では、生成AIそのものの性質、特に生成AIによる処理の特徴を念頭に置いて

生成AIによりできるようになる機能は何か
生成AI機能を開発するにあたり注意すべきことは何か

を正しく理解できることを目指しています。

AI機能開発の特徴

というわけで、生成AIそのものの特徴とそれに伴って機能開発で意識すべきことから話していきます。従来開発とAI開発との根本的な違いは、やはり以下になるでしょう。

	従来開発	AI開発
処理の仕組み	決定論的	確率的
品質定義	客観的に定まる	主観性を含む

ここでは具体的になぜこうなるのかについては説明しませんが、この主張自体は広く受け入れられるものと想像します。この根本的な違いにより、開発にあたって以下の違いが出てきます。

観点	従来開発	AI開発
開発アプローチ	事前に詳細設計を固める	開発と並行して検証＆調整を重ねる
検証方法	テストパターンを洗い出す	典型的なパターンで試す
改善方法	ロジックの修正	プロンプトやデータの調整

すると、各観点に対して発生する課題と対応策は（単純には）以下のようになるでしょう。

観点	発生する課題	対応策
開発アプローチ	事前設計ではカバーしきれない	段階的な開発や検証サイクルの導入
検証方法	想定外のケースが発生しやすくなる	本番に近いデータを用いる
改善方法	エラー原因の特定が難しく、調整にも時間がかかる	継続的なモニタリングや改善プロセス

このように文章で書くと当然のことのように感じてしまうかもしれませんし、捉えようによっては「従来開発でも考えなければいけないことでは？」と言われてしまいそうです。しかし、これらの事項を改めて整理することで、開発の要所要所にて重要ポイントが伝わるはずなのです。何かうまくいかないなあ、と思った時にはこの根本的な違いを思い出すといいでしょう。

兎にも角にも、AI機能開発の特徴は把握できたということにしてそろそろ本題に行きましょう。

AI機能開発方法論の全体像

前置きが長くなってしまいましたが、ここから「AI機能開発方法論」について紹介していきます。我々で検討・構築している「AI機能開発方法論」では、開発プロセスを大きく以下の3ステップに分けています。

Step1: AIシナリオデザイン
Step2: プレビュー版の開発と検証
Step3: 正式版の利用と継続改善

それぞれのステップにおいて、概要と特徴は以下のとおりです。

Step1: AIシナリオデザイン

生成AIを用いて実現すべき業務（AIシナリオ）を検討します。初めにお客様の業務内容を深く分析した上でモックを用いた検証等も行い、業務要件との擦り合わせを行った上でシナリオを確定させます。

Step2: プレビュー版の開発と検証

確定したシナリオを一部ユーザーや一部機能のみに限定して実現し、プレビュー版として利用・検証を行います。正式版の利用に向け、「開発」「運用」「フィードバックの反映」を繰り返すことにより十分な品質を持った機能実現を目指します。

Step3: 正式版の利用と継続改善

正式版の利用開始とともに、継続的な改善を行います。単純な機能追加や保守業務だけでなく、生成AI機能特有のモデルの更新などに伴う運用・保守体制を整えます。

なお、この記事では「Step1: AIシナリオデザイン」の一部についてのみご紹介いたします。機能開発にあたってコアとなる「AIシナリオ」の簡単な説明とStep1の進め方に関する概略についての記載となります。

AIシナリオデザインとその進め方

そもそも「AIシナリオ」とは？

ここまで当然のように「AIシナリオデザイン」と言う言葉を使ってきたのですが、実はこの言葉、我々で勝手に作った言葉です。「AIシナリオ」とは、ここでは以下のように定義しています。

AIシナリオ・・・「人」「AI」「システム」による協働業務プロセス

なんのことやらと言う感じがしますね。私もそう思います。なぜこのような言葉を使うことにしたのか、簡単にお話しします。まず前提として、今後の生成AIの発展により業務は「人」「システム」「AI」が組み込まれた三者による協働業務へと変わっていくと考えています。これまでは人がシステムを利用していたわけですが、そこにAIが加わった結果「三者による協働業務」と捉えるべきでは？ということです。「人」「システム」「AI」による三者協働業務において、脚本を書くように、それぞれの役割と連携の流れを明確に定義する必要があります。この業務プロセス全体の流れを「シナリオ」として整理することで、複雑な協働関係を具体的かつ実行可能な形で設計しようという目論見です。この考え方はかなり大事だと思っています。「AI」と「従来システム」はよく対照的に扱われますが、業務分析の観点において対照的になるべきは「人」と「AI」です。これまで「人」が「システム」を利用することで業務を行っていたわけですが、「AI」に置き換わるのは「システム」が担っていた部分でなく「人」が行なっていた部分です。「人」と「AI」が「システム」を利用し、互いに相互作用しながら業務をこなしていく。このイメージを持つことが大切だと思っています。~~これがなかなか伝わらない。~~

AIシナリオデザインの進め方

さて、「AI機能開発方法論の全体像」のところで記載した、Step1でやることを再掲します。

生成AIを用いて実現すべき業務（AIシナリオ）を検討します。初めにお客様の業務内容を深く分析した上でモックを用いた検証等も行い、業務要件との擦り合わせを行った上でシナリオを確定させます。

これを実行するために、このStepをさらに以下のように分けてみました。

業務分析とAIシナリオの発案
- お客様の課題を把握し、どのようなAIシナリオを導入すべきか考える
AIシナリオの検討
- 検討したAIシナリオをどう実装すべきか考える
モックによるAIシナリオ検証
- 検討したAIシナリオの妥当性・実現可能性を検証する

それぞれ書いているとあまりにも長くなってしまうことに気づいてしまったので、ここでは「業務分析とAIシナリオの発案」のパートにのみ触れることとさせてください。

業務分析とAIシナリオの発案

ここでやることは、お客様の課題を把握し、どのようなAIシナリオを導入すべきか考えることになります。生成AIには抽象度の高い業務を担わせることができるとお伝えしましたが、その結果として、より業務の深い部分に踏みこむことになります。多くの場合において、業務の深い部分では人が無意識のうちに行っている判断が介在するためと個人的には考えています。そのため、導入するAIシナリオを検討する前には必ず業務分析を念入りに行う必要があるでしょう。業務分析をすることにより既存業務の課題が浮き彫りになり、課題の解決方法としてAIが適切か否かを精査・判断するというのが基本的な流れになるかと思います。

実際にAIシナリオを発案するにあたり、シナリオを構成する各業務を分類しておくと良いでしょう。いつでも分類は大事です。まず、課題を解決する方法は既存業務の置換だけでなく、AIだからこそできる業務を新たに導入することになるかもしれません。なので大きく、「既存業務の置換」と「新規業務の創発」に分かれるかと思います。それぞれどう発想していくべきでしょうか。社内への展開をする際には、社内でも（ある程度は）認識されている社内事例を交えて業務の分類と発案方法を提示していますが、ここでは問い合わせ対応の場合で考えます。問い合わせ対応でいうならば、単純化して考えれば

どのような問い合わせ（+それに対する回答）が来るか分析・分類
分析結果をもとに、回答に必要な情報と回答するまでの判断プロセスを検討
AIに回答可能な領域を特定

こんな流れになります。こちらは「既存業務の置換」に当たるわけですが、大雑把には既存の業務フローを洗い出したうえで業務を分解し、どの部分がAIに置き換え可能かを検討すると考えておくのがわかりやすいでしょう。その際、業務に対するAIの「適性」と「効果」の2軸で考えると良いでしょう。どんなにAIに向いていても、導入効果が小さければ意味があまりありません。適性のない業務をAIに担わせるべきでないことは言わずもがなです。

具体例として、私が開発に携わったものを挙げてみます。

具体例: 与信確認と反社チェックのAIによる自動化

与信確認と反社チェックとは、企業と取引を行う際にその取引先企業に関する信用度や反社会性力との関わりの有無を確認する業務です（本来、与信確認と反社チェックはそれぞれ別の業務です）。詳細は省きますが、弊社では担当者が企業に関する情報を調査しており、多くの工数を消費しておりました。そこで、AIを使って自動化（または省力化）できないか？となったわけです。

AIシナリオの発案は以下のように進められました（ここではそれ以降の開発工程は省略します）。

AsIs業務フローの整理
担当者へのヒアリング
AIシナリオ策定

最初の「1. AsIs業務フローの整理」では、業務に携わる担当者と現行システムを調査しました。現在の業務フローにて作業を担当している「人」と利用している「システム」を特定したわけです。

次に「2. 担当者へのヒアリング」にて、担当者が何をどうやって判断しているのか、直接ヒアリングを行いながら確認しました。「人」である担当者が「システム」にあるどの情報を取得し、どのような基準をもとに判断を下し、「システム」に何を返すのか、ですね。

最後に「3. AIシナリオ策定」でAIシナリオを検討しました。すでに担当者が何をしているのかはわかっているので、あとは必要なデータと判断基準をAIに渡せれば同じことができるはずです。

ということで、最終的にAIシナリオとして組み込むこととなった業務は以下の通りです（ここでは反社チェック部分のみ列挙します）。

PDF抽出：外部サービスから取得してきたPDFを読み込み、企業情報を抽出
企業情報の要約：企業に関するWeb検索結果を要約し、業務内容を要約
企業の反社チェック：外部から取得した情報をもとに、必要に応じてWeb検索を行い企業の反社会勢力との関連性有無を判断
代表者の反社チェック：3と同様に、代表者に関しても反社会勢力との関連性有無を判断
総合反社チェック3と4の結果をもとに、企業に関する反社チェックを総合判断

当然ながら最終チェックは人が行う必要がありますから、人が与信反社チェックを起動してからAIによる結果を確認して最終判断を下すまでの一連の流れがAIシナリオということになります。このAIシナリオの中では、「人」「AI」「システム」の三者間で情報のやり取りをしながら適宜判断を行なっているのが想像できるでしょうか？

さて、この与信反社チェックでのAIシナリオにて組み込むこととなった業務ですが、以下のように分類できます（総合反社チェックは別枠とします）。

既存業務の置換	新規業務の創発
PDF抽出企業の反社チェック	企業情報の要約代表者の反社チェック

既存業務について、これまでは人がPDFを見て手動で書き写していたのですが、AIに読み込ませることで自動化可能になりました。企業の反社チェックについても、人が外部サービスを利用して判断していたものを自動化しました。一方、新規業務については、AIの導入によって大量のWebサイトの検索や取引先のWebサイトから代表者を自動取得し検索が可能になったために今回新たに導入することになったものです。どうしても人が行う業務においては費用対効果の関係でできなかった業務があったのですが、AI導入により可能となりました。実はこちら、実際に担当者の方にヒアリングすることで明示的に実装することとなった業務です。「本当はやりたいけど大変で、その時々に判断している」と言った声を受けて実現した機能であり、AsIs業務には当然記載されていなかったのです。実際に業務を行っている人の暗黙の判断が介在している良い例かと思います。

それ以降の進め方

さて、ここからはどうシステムに組み込んでいくのかを視野に入れつつ、徐々に具体的な話に進んでいきます。

検討したAIシナリオに基づく技術アプローチの選択
UIパターンの検討
対象機能の選定

といった具合です。これをもとにAIシナリオを確定し、さらに「Step2: プレビュー版の開発と検証」「Step3: 正式版の利用と継続改善」と進めていけば、無事、AI機能の開発完了！となる算段です。これ以降の具体的な方法論については、また別の機会があればご紹介いたします。

つらつらと方法論について（だいぶ端折っておりますが）書いてまいりました。が、この方法論は実際に案件に参画しながら洗練していくつもりですし、そうあるべきと考えています。あくまでもこれまでに得た経験と考察をもととしていること、ご承知おきくださいませ。ここまでご覧いただきありがとうございました。

おまけ、だけど大事なこと：発生しやすい課題とその対策

最後に、ここは最初から意識しておいた方が良いだろうということがあるので簡単に触れておきます。

観点	課題	対策
お客様の体制について	「検証と改善を繰り返す」には、データの本質と深い業務理解が必要で、技術者だけでは不十分になりがち。	なるべく「データの本質と業務内容」を深く理解しているお客様を巻き込む。
お客様側の懸念事項について	漠然としたAIへの不安があり、技術者のAIに対するギャップが発生しやすい。	「段階的な導入」や「明瞭なプロセス」を構築し、かつ十分な説明を行う。