nice2have 活動レポート AI駆動開発研修（第1回）― システムの裏側から業務の見直し方まで、一日で扱ったこと

はじめに

ある自治体の職員の皆さまを対象に、全2回のAI駆動開発研修の第1回を実施しました。第2回はハンズオンで実際に作っていただく回になるため、この日は作る前に押さえておきたいことを一日かけて扱う構成にしています。

午前に「システムはこう動いている」と「AIとは何か・自治体DXとAIの事例」、午後に「AI適用対象をどう見つけるか」とワークショップ。ワークショップで選んでいただいた業務が、翌月の第2回でそのまま開発のお題になります。

昨年度の続きから始める

この団体では昨年度もAI駆動開発研修を実施しています。職員の方がAIと対話してツールを開発し、成果を発表するところまでを体験していただく形で、タスク管理ツール、イベント時の駐車場の空き状況共有、キーワード抽出ツール、空き家のバーチャル内見の4つが生まれました。

当時の構成は、開発がVSCode＋Cline、公開はAWS EC2＋IISを人が手で構築するというもので、開発はAI・クラウドは人力という時代の型です。この1年でその前提が変わりました。今回のポイントは、クラウドで動かして公開するところまでAIに任せられるようになったことです。人が手で組んでいた部分が、対話で片付くようになりました。

それを最初に見ていただくところから始めました。参加者の方に「業務でこんなモノがあったら」というお題を出していただき、その場で私がAIに作らせます。目の前で組み上がったものを、そのままクラウドへ公開して、URLとQRコードをお伝えしました。皆さんのスマートフォンから実際に開いていただくと、本当に動いていること、どんなものができたのかがその場で分かります。この日の最終ゴールを先に体感していただいてから、中身の話に入る構成にしています。

Part 1｜システムはこう動いている

最初は、画面の裏で何が動いているかの復習です。見た目が同じWebサイトでも、できあがったページをそのまま返す静的サイトと、データからその場でページを組み立てて返す動的サイトに分かれます。市ホームページのお知らせは前者、施設予約・電子申請・図書館の蔵書検索は後者。生成AIも動的側の仕組みの上で動いています。

続いてCDNを、ページのコピーを利用者の近くに置いて本体サーバーを守る仕組みとして扱いました。大手の例では330都市以上、国内は東京・大阪・福岡・沖縄の4都市。災害時にアクセスが集中しやすい行政サイトの「落ちない」ための手段としても使われています。

ここまでを押さえておくと何が変わるか、という話をこの区切りでしています。裏側の仕組みを言葉で持っていると、AIへの指示が「なんとなくWebで見られるように」から「静的なページとして書き出して、CDNの後ろに置いて」に変わります。指示が具体的なほど、AIとのやり取りの往復は減ります。AIは入力と出力の量で課金されるので、往復が減れば時間だけでなく費用も減る。技術を学ぶ意味は、自分で作れるようになることだけでなく、AIに任せるときの指示の精度が上がるところにもあります。

そのうえで三層分離のおさらいに入ります。ここは職員の方に手を動かしていただく話ではなく、庁内でAIを使おうとしたときに、どのセグメントにどんなデータがあるかで、AI環境をどこで動かさなければならないかが変わるためです。三層の対策はデータを混ぜない・外に漏らさないための設計であって、AIを使ってはいけないという規定ではありません。マイナンバー利用事務系はガバメントクラウドと専用線でつながっているので、その閉域の中にAIを置けば、個人情報を扱う業務でもデータを外に出さずに使えます。奈良市が庁内約1,000台のPC環境を対象に、インターネット系の次の段階として閉域へ広げた例を紹介しました。

Part 2｜AIの仕組みと、いま国が決めていること

AIの仕組みは、次に来る言葉を確率で選び続けているという説明から入ります。あわせてトークンの話をして、料金も一度に扱える量もトークンで決まること、チャットを替えると忘れるのは仕様なので、大事な前提は文書にして毎回渡すことを確認しました。

そこからMCPへ進みます。AIと外部サービスをつなぐ共通規格で、私自身が毎日使っている構成（Claude CodeからGmail・カレンダー・Notionを読み書きする形）をそのままお見せしました。届いた問い合わせを読ませて返信の内容を考えさせ、Gmailに下書きまで作らせる。候補日を求められたときは、カレンダーを見て空いている枠を押さえたうえで、その内容で返信の下書きを作らせる。返信の中身を考えるときには、Notionに置いた議事録やメモを読みに行かせて、そこから書き起こさせる。

ポイントは、各サービスから情報をコピーしてAIに貼り付けているのではないところです。必要に応じてAIのほうがそれぞれのサービスへ読みに行き、集めた情報をもとに総合的に処理してくれます。そういうことができる時代になりました。

続いてRAGです。LLMが学習していない情報、そもそも外に出ていない情報をもとに答えさせるための仕組みで、学習後の制度改正も庁内の要綱も知らないAIに、答えさせる前に自団体の文書を読ませます。もう一つの使いどころが精度で、正しい情報にもとづいて答えなければならない場面では、根拠となる箇所や出典を添えて引用させる形にして、回答の確からしさを上げています。

そのうえでClaude Codeの位置づけを扱いました。チャット型AIが文章やコードの断片を返すのに対し、Claude Codeはファイルの作成・編集・コマンド実行まで自分で行います。要件定義 → Planで調整 → Actで実装 → 作業を承認 → 個別に改良という5ステップを紹介し、5から2へ戻るループが本体であることも添えています。

作るものについては、2つの型に分けて考えていただきます。完成品にAIが入っていないA型（貸出簿・集計・予約管理）は費用がほぼゼロで毎回同じ動きをします。動くたびAIに聞きに行くB型（FAQボット・要約・判定の下ごしらえ）は利用料が続き、同じ入力でも答えが揺れることがあります。用途によっては、人の確認を設計に入れておく必要が出てくるかもしれません。次回のお題を考えるときの分かれ目になる話です。

国の動向は、7月に閣議決定された「デジタル社会の実現に向けた重点計画」を4論点に整理して扱いました。ガバメントAI「源内」の全府省庁実証、デジタル庁調達へのAI駆動開発の試験導入、改正頻度の高い制度からのRules as Code着手、行政システムのMCP対応方針の決定。この1年で具体化が進み、論点は「AIを使うか」からAIを前提に調達と業務をどう組み替えるかのほうへ移っています。生成AIの導入率が都道府県・指定都市100％に対して市区町村46％という開きも、あわせて確認しました。

源内については、デジタル庁が内製したのはモデルではなく行政向けの利用環境である、という整理をしています。モデルは商用の大規模言語モデルを使い分ける構成で、あとから差し替えられるようになっています。自治体はOSS（MITライセンス、2026年4月公開）をGitHubから入手して自前構築できます。当社では源内をベースにした体感環境「ひふみAI」を lg.jp 職員向けに無料公開しているので、この日はその操作を録画したデモ動画をお見せして、認証・ログ・利用管理を入口で一元統制するとはどういうことかを見ていただきました。

もう一段、コードを書かずにAIアプリを組み立てるDifyも扱いました。画面の上でプロンプト（指示）＋知識（自分の文書）＋ワークフロー（手順）の部品を線でつなぐとAIアプリになる、という層です。資料には実際のワークフロー画面を載せ、そのあと実物を操作してお見せしました。

行政での広がりとしては、東京都の生成AI共通基盤「A1」も同じ発想をOSSで内製し、2026年4月に都職員 約6万人へ本格運用しています。契約仕様書案の作成支援や、議事録を使った答弁検討支援が実際に動いている例です。

あわせて、その日いちばん新しいところの使い方もデモでお見せしています。Canvaでテキストから画像を生成して自治体PRポスターを作るところ、Chrome拡張のClaudeにいま開いているページを読ませて、調べる・まとめる・入力するまでを任せるところ。開発の道具だけでなく、日々の資料づくりや画面上の作業のほうにもAIが入ってきている、という具合です。

ここまで、源内・Dify・Canva・Chrome拡張と、あえて種類の違う使い方を並べてお見せしました。この時間でいちばん大事だと考えているのは、個々のツールの操作を覚えていただくことではなく、いま何ができるのかを知っていただくことです。できることの幅を一度見ておくと、日々の業務で困りごとに当たったときに「これはあのやり方でできるんじゃないか」と発想できるようになります。作る対象を自分で見つけられるかどうかは、ここで決まります。

セキュリティにも、AIが大きく関わってきた

AIの話は、ここでセキュリティに接続します。まず攻撃側の現在地から入りました。侵入から横展開開始までの平均が29分、最速記録が27秒、検知のうち82％がマルウェア不使用。IPA「情報セキュリティ10大脅威 2026」では、AIの利用をめぐるサイバーリスクが初選出で3位に入っています。

そのAIリスクを、資料では3方向に分けています。①職員が入れすぎる・鵜呑みにする、②攻撃者がAIをだます、③攻撃者がAIで攻撃を作る。①②は使い方のルールで、③は確認の手順で備えるという整理で、③についてはAIを使っていない自治体にも降りかかります。

③の実際として、フィッシングの文面を新旧で並べました。かつては変な字や怪しいドメインで見抜けたものが、いまは日本語も文脈も自然で、見た目からは判別できません。残る手がかりは要求の中身のほうなので、お金・パスワード・急がせる要素が出てきたら別経路で確認する、という手順で守ります。訓練の目的も見抜ける人を作ることから、必ず手順を踏む組織を作ることへ移っています。

使う側のリスクは、昔からある話のAI版と、AIならではの新しいものの2種類に分けて整理します。後者の代表としてプロンプトインジェクションを扱いました。「この議事録を3行で要約して」と頼んだだけなのに、文書の中に埋め込まれた指示にAIが従ってしまう、という形です。埋め込み方は目に見えません。白い背景に白い文字で書く、極端に小さい文字で入れる、ヘッダーやフッター・図の裏・HTMLのコメントなど人が読まない場所に置く。人が開いた画面には何も出ていないのに、AIはその文字列を指示として読みます。

そのうえで、使い方を5つのパターンに分けて、それぞれの危なさと守り方を並べています。要約・下書き／庁内資料の横断検索／住民問い合わせへの下書き回答／開発・データ処理／まとめて連続実行。パターンが変われば対策も変わるので、一律の禁止では現場が動かなくなります。シャドーAI対策として、職員を疑うより先に安全な選択肢を用意する、という話もここで扱いました。

どこまでを目指すか

ここで期待値の設定に入ります。作るところまではAIで進んでも、公開する環境やセキュリティを越えられずに試作止まりになります。対話で越えることはできますが、それぞれの層に知見を持って対話する必要があります。さらに進むと、設計と構築までAIに任せて壁そのものが消える段になります。本研修は1を通り、2を体験し、3の世界を見る構成です。

到達目標は2つに分けてお示ししました。レベル1は、試作・部署内ツールは自分で作り、住民向け・全庁展開などの実運用は情シスやベンダーに引き継ぐ形。レベル2は、稼働環境とセキュリティの知識を持ってAIにざっくりでも正しい方向の指示が出せる状態で、こちらは1日で到達するものではなく継続学習が前提になります。

そのどちらを選ぶにしても、人の側に残る仕事は要件定義です。ゴールを与えればAIが計画して仕上げるところまで来た以上、ゴールを言葉にする作業が核心になります。ただ、多くの人は今あるシステム・様式・手順の枠で考えてしまうため、必要な力を2つに分けて整理しました。

2つ目の力がなぜ要るのかも、あわせてお話ししました。AIは従量課金なので、作れば作るほど、やり取りを重ねるほど費用がかさみます。時間についても同じで、あいまいな指示から始めると、直しては投げ直すという往復が増え、完成までが遠くなります。要件をはっきりさせてから渡せば、少ないやり取りで思ったとおりのものにたどり着けます。要件定義は、コストの面でも時間の面でも効いてくる作業です。

Part 3｜適用対象をどう見つけるか

午前でAI駆動開発の壁がどこにあるかを見ていただいたうえで、午後は「では何を改善すればいいのか」に入ります。いきなり対象を挙げてくださいと言われても、なかなか思いつくものではありません。そこでこの時間は、その見つけ方と、どんなポイントで見つければよいかという着眼点のほうをお伝えしました。考え方を持ったうえで日々の業務に戻っていただくと、どこに当てはめられそうかが自然と想像できるようになります。

まずは、AIやシステムを選ぶ前の話から始めます。サービスデザインの考え方では、誰の・どんな場面の・何のつまずきかを先に書き切る。対象業務選びはセンスではなく手順だ、という前提で、①困りごとから出発する ②件数×時間や差戻し理由を数える ③型を当てる、の3段で進めていただきました。東京都がサービスデザインガイドライン・サービスキャンバス・ユーザーテストとして全庁の作り方を文書化していることも紹介しています。

③で当てる型は、8つを例示しました。もちろんこの8つに限られるものではありませんが、事例名ではなく現場での見え方のほうを見出しに置いているので、自分の職場に当てはまる行があるかどうかで判断できます。

次にBPRです。ムダなプロセスのままデジタル化すると「ムダの高速化」になるため、システム導入の前に業務そのものを見直します。可視化の道具としてスイムレーン図の描き方を扱い、図を描いたあとに探すムダのサイン4つを確認しました。

1. 往復

   レーンを何度も行き来している。矢印が上下にジグザグしている場所を見る

2. 滞留

   次の作業まで待たされている。箱と箱の間が時間的に空いている場所を見る

3. 重複

   同じ情報を何度も転記・入力している。似た名前の箱が複数レーンにある場所を見る

4. 承認過多

   決裁・確認の階層が多すぎる。ひし形・決裁の箱が連続している場所を見る

印を付けた箇所には、E→C→R→Sの順に問いを当てます。改善効果はEliminate（なくす）がいちばん大きく、Simplify（簡単にする）は最後の手段。いきなり自動化に飛びつかないための順番です。

効果は工程数・受け渡し回数・所要日数で数えます。架空の旅費精算の例では、9工程→4工程、受け渡し6回→1回、所要5日→1日という形にして、ビフォーアフターを数字で示す練習をしていただきました。

Part 4｜次回のお題を決める

最後は個別ワークです。ここまでの内容をすべて踏まえたうえで、自分の担当する業務からひとつを選び、それがいまどんな形で流れているのかを描き、どこに改善や変革の余地があるのかまでをまとめていただきました。

そのうえで、第2回での対処方法として、AI駆動開発によるツールやサービス開発で埋められる部分はどこかを言語化し、要件の形にしていく。ここがこの時間のポイントです。特定の業務を上手に直すことよりも、いろいろな対象に当てはめられる一連の流れを体感していただくことを目的にしています。

最後にお見せした事例

締めくくりに、北海道芽室町のMADOを紹介しました。プログラミングの専門知識を持たない窓口職員がAIに指示を出しながら窓口業務支援システムを内製し、情報システム担当と協議のうえマイナンバー系の分離されたネットワーク内で稼働させ、MITライセンスのOSSとして公開している例です。

ここでお伝えしたかったのは、作れたその先に残る課題のほうでした。芽室町はそれを3つとも公開しています。

3つは「これを作った職員が異動したら、いま動いているこの仕組みはどうなるのか」という一本の軸でつながっています。数年ごとの異動を前提とする行政では現在進行形のリスクなので、作ったあとに誰が支えるかまでを含めて考える必要があります。第2回で実際に作っていただく前に、この話を置いておきたいと考えました。

おわりに

まとめは3点にしました。一つ目は、触れたことがないものは発想できないので、一度やったことがあるという体験を届けることです。二つ目は、全員をスペシャリストにはできないので、全職員は基礎リテラシー、管理職は判断できる知見、推進者は実践スキルというように層を分けて設計することです。三つ目は、棚卸しで現在地を知る → 身近な改善を試す → 見せて広げる、という順で小さく積んでいくことです。予算がついていない、上層部の後押しがまだ得られていない、という状況も少なくありません。環境によりますが、そういうときこそ手の届く範囲から小さく積んでいくことが効いてきます。

そのうえで、この日いちばんの到達点は、第2回に向けた線引きを自分たちで置けるようになったことだと考えています。作るものを絞って自分たちの手が届く範囲を先に定義するのか、届かない部分を誰かと分担しながらもう一段上を目指すのか。この判断は、稼働環境やセキュリティ、コストの桁がどうなっているかを知らないままでは下せません。技術を先に扱ったのは、そこを想像できる状態にしていただくためでした。第2回のレポートは、実施後に改めて公開する予定です。

お手伝いできること

この研修は、扱う範囲を貴団体の状況に合わせて組み替えられる形にしています。作る体験に重心を置くこともできますし、この日のように作る前に押さえる話と、対象業務を決めるワークショップを中心に組むこともできます。AI利用ポリシーの策定支援や、年間アドバイザーとしての伴走と組み合わせることも可能です。