2024年11月7日（木）、デジタル庁で「AIアイデアソン・ハッカソン」を実施しました。デジタル庁からだけでなく、東京都や都の外郭団体であるGovTech東京、日本マイクロソフト、グーグル・クラウド・ジャパン、アマゾンウェブサービスジャパン、ELYZAからもAIエンジニアが参加し、約40名で、AIのプロトタイプ（業務改善アプリの試作品）開発を行う非常に活気あるイベントでした。

1.イベントの概要：デジタル庁職員の相談をその場で解決

このイベントの一番の目的は、現場のAIエンジニアと行政職員の間で開き続けてきた認知ギャップを埋めることでした。特にこの2年の生成AIの発展はすさまじく、「今時のAIなら、このくらいのことはさっと実現できる」という感覚が現場のAIエンジニアと行政職員の間でかなり開いていると感じます。

デジタル庁ではAIを活用した行政業務の効率化を実証し、公務員人口が減少する人口減少社会でも行政サービスの維持・向上を実現できる状態を目指しています。

AIアイデアソン・ハッカソンは、大まかに以下の流れで実施しました。

1. 職員が「これAIでなんとかできない？」という相談を持ち込む

2. その場でAIエンジニアがプロトタイピングをし、デモを行う

3. コメンテータの前で、その日に作った一部をデモし、コメントをもらう

当日は1と2を10～15時まで実施し、プロトタイプ開発時間は5時間ほどでした。

コメンテータには、デジタル庁から平将明デジタル大臣のほか、デジタル監や統括官の3名、東京都からは宮坂学副知事のほか、デジタルサービス局長の2名、GovTech東京からは業務執行理事の計6名が参加しました。

2.イベントの特徴：一般的なハッカソンとの違い

このイベントはAIアイデアソン・ハッカソンと銘打っていますが、一般的なハッカソンと比べて、以下のような違いがありました。

1. アイデアを持った人と開発する人が分離している

2. 開発する人が1テーマではなく複数テーマを開発することもある

3. どんなお題が来るのかが開発者は事前にわからない

4. 最後に序列をつけることをしない

これらの違いが良い方向に作用して、当日の5時間だけで38個もデモ開発ができたと考えています。どのようなイベント形式だったかを、もう少し詳細に解説します。

もっとも重要な点は「事前に開発パターンを検討しておくこと」と「それぞれの開発パターンで少し手直しすれば汎用的に使えるように仕込みをしておくこと」です。

本記事の付録として、記事後半では当日に作られたデモ一覧、その開発パターン、アイデアを開発パターンに割り当てる生成AIのプロンプト案を紹介します。

3.イベントの形式：プロトタイプ開発体制

●相談を開発チームに振り分ける「相談窓口」

当日のイベントではAIエンジニアのチームは「相談窓口」と「開発チーム」の2種類で構成されていました。相談窓口は1チームで、開発チームは協力いただいた企業ごとに分かれていました。

相談窓口の役割は、「この業務をAIで何とかしたい」という相談を受け（要求分析）、相談内容からどんな開発パターンの要件に落とし込めるのか（要件定義と簡易な設計）、どこの開発チームで担当するかを決め、実際に開発チームに相談してきた人とその要件を接続する、といったものでした。

これをだいたい1案件につき、5分～10分くらいでさばいていました。この速度を実現できたのは「当日中にデモができるための条件」と「プロトタイプの開発パターン」を事前に頭に入れておいたからでした。この役割はデジタル庁のAIエンジニアが担いました（こちらの詳細は少し長くなるので付録に載せます）。

●プロトタイプを開発する「開発チーム」

開発チームは協力事業者ごとに構成されており、クラウドサービスプロバイダーの場合はどこでもだいたい同じことができます。どの開発チームで担当するか、はその時の忙しさ度合いと、対応する開発パターンを事前に仕込んでいたかで判断しました。

開発チームの役割は、相談窓口から送られてきたざっくり要件と開発パターン案をもとに相談者と一緒にプロトタイプ開発をすることです。相談者の要望に応じて、事前に仕込んでいた開発パターンをカスタマイズすることでプロトタイプを開発しました。

特に昨今の生成AIでは、プロンプトと呼ばれる入力テキストをいじるだけで多様な自然言語処理課題が解けるため、要望に応じたカスタマイズのやりやすさもできる範囲も格段に進歩しました。

生成AIの背後にある基盤モデルもこの2年ほどで大幅に進歩したため、長文を雑に放り投げるだけでも、かなりそれっぽい答えが得られるようになってきました。

デジタル庁のAIエンジニアも協力事業者ごとの開発チームに一部参加し、協働することで短期間での職員のAIスキルの大幅な向上も観測できました。

4.イベントの成果：「5時間で38個のデモ開発」のインパクト

こうした形式により、アイデアを持ち込んだ人からすると「その日に動くものが見られる」といったうれしさがありますし、開発者側も事前準備は開発パターンごとの汎用的な仕込み（このイベント外でも使いまわせる）くらいで、当日にその仕込みの良し悪しを試せる、といったメリットがありました。

なによりもこの形式ですと、短い期間で大量にデモができます。実際に、この日は5時間で38個のデモを開発することができました。

このように適切な仕込みをしておけば、AIによる業務改善の最初の一歩はそこまで難しくありません。イベント終了後、宮坂副知事が報道陣の取材に対してコメントしたように、近い将来の行政の職場はAIによる業務改善での「自炊」の選択肢をとれるように、仕込みを終わらせたAIエンジニアが身近にいるような「ダイニングキッチン」のようなものに変わるかもしれません。

5.今後の展開

今後、このイベント形式をより発展させ、
（1）AIで業務改善を行いたい職員が即AIの恩恵を受けられる
（2）AIエンジニアに実際の現場ニーズが伝わりやすくする
（3）AIエンジニアスキルを身に付けたい職員を急成長できる
といった状態を作りたいと思います。

最終的にはこの形式はイベントとしてではなく、職場で持続的に存在する組織状態にすることが理想です。

今回のような「事業者ごとの開発チーム」は必然ではありませんが、複数組織の開発チームの中をイベント的に行き来することで自組織が「技術的に局所解に陥ってないか」、「もっと良い方法はないか」を知る良いきっかけになることは間違いないです。そのような仕掛けも考えていきたいです。

この形式を、より早く安く良いものにしていくために、相談窓口のAI化や開発パターンの仕込みも重要だと考えます。現時点で検討しているものについては付録を参照ください。

また、今回作成したプロトタイプをイベント限定のものにしないように、作成したプロトタイプを安定して職員に届け、改善し続けられる状態が重要になってきます。これにはやはり内製もできるエンジニア体制が重要ですので、採用活動に力を入れていきたいです。

◆求人票のリンクです。興味ある方は応募いただけると嬉しいです。

• 【O_01】データサイエンティスト（AI利活用） - デジタル庁

• 【A_04】プロジェクトマネージャー（生成AI利活用推進） - デジタル庁

さらに踏み込むと、今回のイベントで「当日中にデモができるための条件」とおいたものを緩和していく方向も、この手のイベントとは別に実施していきます。

この条件は大雑把に3つあり、
（1）職員の内部利用でそこまでの品質は求められていない
（2）その処理に必要なデータが揃っている
（3）現場職員がAIの期待入出力を決められる
です。

（1）については品質が高く求められるユースケースの特定やそのユースケースでの安全なAI利活用についての検討を十分に行い、その結果のドキュメント化を行っていきます。（関連：テキスト生成AI利活用におけるリスクへの対策ガイドブック（α版））
（2）については行政関連のデータのアクセシビリティの改善等が改善策と考えられ、AI自体のオープンデータ戦略についての検討を行っています。
（3）については現状業務の一部AIサポートの範囲でしたら十分可能ですが、AIの恩恵を最大化するために業務フロー側をAIに応じた改善することも非常に重要です。今回の形式では、既存の業務フローの延長以上の発想がなかなか出てこないため。新しい形式について検討中です。

以降、開発パターンの適切な仕込みとはどのようなものか、当日にどのように活かされたかについて少し踏み込んだ解説を行います。

付録

●実際に作られたデモとその開発パターンとその実現方法

開発パターン1

概要

• 大規模言語モデルベースの生成AIでプロンプトチューニング。

• pdfやpptx等のファイルはまずは手動でプロンプトにコピペで試す。

• Webスクレイピングや検索APIや内部システムとデータ連携が必要な場合でもプロトタイピング時点では一部データを用いて実施する。

どのようなケースで採用するか

• 入出力がテキストだけで入力文字数が高々1000文字から10万文字程度のオーダー。

• 入力がpdfやpptx等が含まれる場合でも、テキスト情報だけ利用かつ入力文字数が高々1000文字から10万文字程度のオーダーで、文章内検索が目的でない場合。

• 入力に画像が含まれる場合も対象。

対応したアイデア例

1. メール文章や仕様書に求められる最低限のルールの箇条書きを与え、そのルールに則ったレビューをAIが行う。
   - レビューだけでなく、内容に関する情報を与え、該当文章の原案作成までAIで行うパターンもありえる。

2. ガイドラインや過去の仕様書等の正解データ等を与え、最低限のルールの箇条書きの原案をAIで作成する。
   - 1の前に2を事前に実行するパターンもありえる。

3. アンケートの自由記述等の大雑把な傾向を把握するため、全文をAI入力し、傾向分析を依頼する。

4. 過去の問い合わせ履歴からFrequently Asked Questions（FAQ）の原案を作成。
   - 問い合わせ履歴数が莫大な場合は、1000件ずつFAQ原案を作らせ、FAQ原案の統合と、統合後FAQの後処理（重複やFAQにふさわしくない内容の除外）をAIで行う方法もある。
   - 元の文字数が長い場合でも、このように分解と統合を繰り返すことで対応可能なケースが増える。

5. 組織名称と役割の一覧をAIに与え、問い合わせ内容や職員スキルを与え、適切な割り当てや配属先をAIに提案させる。

実装例

• 多くの大規模言語モデルのプレイグラウンド画面やWeb APIで実現可能。

  • Azure AI Studioや、AWS Bedrock, Vertex AI Studio, ELYZA App Platform等。

  • ただしマルチモーダル対応やWeb検索でのグラウンディング、入出力文字数の制限等で機能面に違いがある他、費用面でも違いが大きいので注意。

  • また、生成AIの出力を生成AIの入力に含めるなどの組み合わせが必要になるケースは、Azure AI Studio プロンプトフローやAWS Bedrock プロンプトフローや、BigQuery Studioや、Python等のスクリプト実行環境やDify等のツール類を採用する。

その他留意点

• 入力文字数によっては利用できる大規模言語モデルに制限がある。

• 入力に画像が含まれる場合は画像対応したマルチモーダルな手法に制限される。

• 出力テキストが構造化必要な場合はプロンプトで指定する（一部、jsonモードも有効）。

• 出力がスライド形式の場合はMarp、フロー図の場合はmermaid形式等をレンダリング可能なテキスト形式を積極的に提案する。

  • Marp形式の場合はcssでスライドのレイアウトを指定できる。このcssもスライドテンプレートのスクリーンショットから生成AIで作成可能。

• 最新の情報が必要な場合はWeb検索でグランディングする手法を提案する。

• 他システムとデータ連携が必須の場合は、RPAツールでの開発パターンと、（必要であれば）生成AIでの処理の2つに分解してプロトタイピングを行う。

開発パターン2

概要

• 文章を全文検索エンジン等に登録し、自然文で検索し、その結果をプロンプトに含める。

どのようなケースで採用するか

• 文章内検索が目的の場合。文章が表形式のものでなく手順書やガイドライン等で与えられている場合。

対応したアイデア例

1. 長大なマニュアルやガイドラインに則ってAIが回答。ただしAIの回答を信頼しすぎず、元のデータソースを参照する利用方法が前提。

実装例

• いわゆるRetrieval-Augmented Generation （RAG）を実現するソリューションが中心。ただし、RAGにも発展形がいくつもあり、デジタル庁では代表的な実装パターンとその手順を検討し、近日公開予定。

• 本イベントではあらかじめ代表的なパターンの手順書と環境を用意し、当日すぐに構築できる状態を作っていた。

  • Azure AI Searchや、AWS Bedrock for knowledge base, Vertex AI Agent, Google NotebookLM等。

その他留意点

• 詳細実装や技術選定が変わるパターンを追加でヒアリングすること。

  • データベースに登録するファイル形式が公式にサポートされているか否か。

  • 文章内の画像データの利用が必須か否か。

    • 必須の場合はOCR等を利用。

  • AI出力に対し元の文章をどのように参照したいか。

開発パターン3

概要

• 表形式のテキストを全文検索エンジン等に登録し、自然文で検索し、その結果をプロンプトに含める。

どのようなケースで採用するか

• 表形式の中のテキストを検索し、その内容に基づいた回答をAIが作成。

対応したアイデア例

1. 過去の問い合わせと回答のExcelがあり、問い合わせ内容に対して近い過去の問い合わせを探し、それに対応する回答を提示する。
   - 対応する回答だけでなく、現在の問い合わせと過去の問い合わせと回答例を大規模言語モデルベースの生成AIに与えることで回答原案まで作成。

実装例

• 検索対象にするテキストと表示するテキストが明確に分かれているケースが多く、その調整ができる手法を採用する。

  • Azure AI Search+Azure AI Studioや、AWS Bedrock for knowledge base+プロンプトフロー, Vertex AI Agent+BigQuery等。

その他留意点

• 文章形式と違い、「検索してほしい行」と「表示してほしい行」がきれいに分かれている可能性が高い。追加でヒアリングし、この要件を明らかにすること。

開発パターン4

概要

• スクリプトを書くか、RPAツールを使うかで対処。

どのようなケースで採用するか

• Webスクレイピングや検索APIや内部システムなどとデータ連携が必要。

対応したアイデア例

1. 特定のWebページに対して更新があるかを検知。

2. メールで来た問い合わせに対して生成AIで作った回答で自動返信。

実装例

• 検索対象にするテキストと表示するテキストが明確に分かれているケースが多く、その調整ができる手法を採用する。

  • Jupyter notebook, Microsoft Power Automate等。

その他留意点

• RPAツールの場合は生成AI関連の処理を呼びだせるか確認。

●相談窓口AIのためのプロンプト案

要望をヒアリングして、開発パターンに落とし込み開発チームへ接続する処理を、イベント当日はデジタル庁のAIエンジニアで行っていたが、そのタスクをAI化できそうであった。

イベント後に、当時を振り返って担当したAIエンジニアがプロンプトの形に落とし込んだものをここで紹介する。

下記をシステムプロンプト等に含め、ユーザーからは「効率化したい業務の内容・業務の課題」と「AIにしてほしいこと」が入力されることを想定している。

なお、AIから返答される質問項目が過剰ぎみな場合もあり、その場合は追加で「開発パターンの判別に必要最小限の質問にしてください」とチャット入力することで抑制される。このように生成AIの一度の入力だけでなく追加の定型文を追加チャットすることで精度向上ができるケースもある。

プロンプト（案）

◆デジタル庁ウェブサイトにて、開催報告を掲載しました。詳細は以下のリンクをご覧ください。