あなたのAI駆動開発パートナー IBM Bob を使ったアプリ開発 #5

01 Oct 2026 - Seigo TANAKA

• 開催日: 2026年9月25日
• 更新履歴
  • 2026-10-01 記事公開

JICUG あなたのAI駆動開発パートナー IBM Bob を使ったアプリ開発 vol.5

ポストまとめ

あなたのAI駆動開発パートナー IBM Bob を使ったアプリ開発 vol.5 - posfie

---

以下、Rimo による AI 議事録をベースに整えたものです。

議論のポイント

• AI駆動開発では、コーディング前に要件定義・基本設計・画面構成・技術選定を具体化することが、後戻りとトークン消費の削減につながる。
• フロントエンドとバックエンドの責務や通信仕様に抜けがあると、実装途中の確認・修正でトークンを大量に消費するため、両者をつなぐ仕様を事前に定義する必要がある。
• AIに任せる範囲だけでなく、「使わない技術・ツール」も明示することで、不要な提案や実装を抑えられる。
• 仕様書は、自然言語によるプログラミングに近い役割を果たしているという認識が共有された。
• 3名の発表を通じて、AIに丸投げするのではなく、開発者の構想・制約・既存の知見を仕様書に落とし込むことが重要だと確認された。

オープニング・運営連絡

• Zoom URLの事前案内メールが送信されていなかったため、開始直前に参加者へ送信した。
• 申し込みは11名で、直前のキャンセルと追加申し込みがあり、開始直前に約3名増加した。
• 今回は、Connpassのアンケート機能とプレイオンの紐付けが設定されていなかった。
• IBMクラウドユーザー会は、IBM社員だけが運営する会ではなく、IBM CloudやIBMのAIに関心を持つユーザーが参加・運営するコミュニティとして紹介された。
• 前回8月はAIハッカソンを開催し、約36名が6チームに分かれて、その場でAIを使ったアプリを作成した。

LT #1：毎月異なるテーマのアプリをAI駆動開発「今月はカイゼン」（鹿野市郎）

目的とアプリ概要

• 今月のテーマは「カイゼン（改善）」。
• 鹿野氏は、製造現場の小集団活動やQC活動を支援するデジタルホワイトボードアプリ「QCプレイブック」を開発した。
• 現場担当者が意見を出しやすくし、意見を整理して改善提案につなげることを目的としている。
• アプリでは、付箋への意見入力、付箋の移動、コメント共有、コネクターによる関連付けなどを行える。
• 現状把握、現状分析、改善計画などのステップごとにホワイトボードを切り替えられ、SWOT分析や特性要因図（フィッシュボーン）などの利用を想定している。

開発プロセス

• 開発の流れは、要件定義、AIによる基本設計、コーディング、検査・修正の順序とした。
• コーディング前に、設計上の不足や未決定事項があればAIから質問させる工程を複数回挟んだ。
• GUIデザイン、インフラ構成、音楽ファイルの配置などを事前に整理し、PowerPointからPDFに変換してIBM Bobに読み込ませた。
• AIが未決定事項を洗い出し、リアルタイム同期方式、バックエンド言語、グラフィックライブラリなどを1問1答形式で決定した。
• 基本設計後にも、コーディング前に追加で決めるべき事項をAIに確認した。

開発結果とトークン消費

• 仕様書作成には約2日を要した一方、初回コーディングは約8分で完了した。
• 発表では、要件定義・基本設計の段階で約5コイン、初回コーディングで約4コインを消費したと説明された。
• 完成後の修正を繰り返すと、過去のコードの読み込み、修正案の作成、適用、検査が発生し、トークン消費が大きく増加した。
• 画面の色や形などを図で具体的に示すことで、修正指示のトークン消費を抑えられる場合があると紹介された。
• 事前設計を充実させることが、コーディング後の修正回数とトークン消費の抑制につながるという所感が共有された。

ライブデモ

• 参加者がブラウザからアプリにアクセスし、プロジェクト名の変更、コメント入力、付箋の作成、付箋の移動、コネクターによる関連付けを試した。
• コメントや付箋をリアルタイムに共有できることを確認した。
• 効果音が実装されており、音声ファイルの配置先、ファイル名、使用シーンを仕様書で細かく指定したことが説明された。
• キャンバスの内容はJSON形式でダウンロードでき、次回に読み込んで同じ状態を再現できる構成となっている。
• ログインすれば、複数の環境をサーバー側に保存する機能も追加できる構想が紹介された。

LT #2：IBM Cloud Code EngineでのWeb 3D + IoTな仕組みをIBM Bobに併走してもらったよもやま話（田中正吾）

システム構成

• 田中正吾氏が、IBM Cloud Code Engine上でWeb 3DとIoTを組み合わせた仕組みをIBM Bobとともに開発した事例を紹介した。
• 主な構成は以下のとおり。
  • バックエンド：Hono（Node.js）
  • フロントエンド：Vue 3、Bootstrap 5
  • 3D表示：BabylonJS
  • IoT連携：MQTT over WebSocket
  • デバイス：M5Stack Atom S3とテープLED
• フロントエンド、3D表示、IoT通信、Code Engineへのデプロイを組み合わせたプロトタイプである。

ライブデモ

• ブラウザ上で3Dオブジェクトを回転させ、回転停止やアングルリセットを操作した。
• ブラウザのボタン操作をCode Engine上のサーバーで受け、MQTT経由でIoTデバイスに送信した。
• M5Stack Atom S3に接続したLEDの点灯・消灯を実演した。
• LED制御は、RGB値をJSONで送信する構成で、赤色を点灯、黒色を消灯として扱った。
• デバイスのMACアドレスを利用してMQTTトピックを一意にする設計が紹介された。

MQTT通信とデバイス構成

• デバイスは外部MQTTブローカーに接続し、該当するトピックをSubscribeしてメッセージを受信する。
• HTTPの定期ポーリングではなく、MQTTブローカーへの接続を維持した状態でメッセージを受信する構成である。
• デバイス側ではArduinoのループ処理内で通信を処理し、おおむね1秒以内に反応する仕組みとして説明された。
• 参加者から、Linux上で動作するラズパイでも同様のIoT制御が可能との補足があった。

仕様書設計とナレッジ管理

• 開発の経緯をAIにノートとして記録させ、設計意図やトラブルの原因を後から参照できるようにした。
• 経緯を蓄積することで、AIが過去の設計や不具合の情報を踏まえて議論しやすくなった。
• GitHubの公開リポジトリに秘密情報を混入させないため、Gitleaksによるシークレット検査を実施した。
• フロントエンド、3D表示、IoT、Code Engineデプロイについて、それぞれ詳細な仕様書を作成した。
• 技術選定、ライブラリのバージョン、3Dオブジェクトの大きさ、カメラアングル、UI部品、MQTTトピック、環境変数、Dockerfileなどを事前に明示した。
• フロントエンドとバックエンドの責務を分け、スコープを広げすぎないようにした。
• Windows環境での環境変数設定に苦労し、この対応で約5コインを消費したと説明された。
• 仕様書と経緯管理を含む初動で約20コイン、試行錯誤やUI調整を含めた全体で約40コイン程度を消費した。
• 詳細な仕様書に開発者の構想や知見を落とし込むことで、Web 3DやIoTのような複数技術を組み合わせた実装でも、比較的スムーズに開発できたという所感が示された。

LT #3：Granite 4.2を組み込んだ自治体・教育機関向け、自己ホスト型・複数ユーザー対応のNotebookLM風ローカルRAG Webアプリケーション開発（西川浩平）

アプリ概要

• 自治体・教育機関向けに、NotebookLM風の自己ホスト型・複数ユーザー対応RAG Webアプリケーションを開発している。
• 認証やマルチユーザー対応、将来の保守に必要な仕様書の保存が求められたため、専用アプリとして構築している。
• 現在はアルファ版として開発・公開しており、会議開催日の翌週から自治体に試用してもらい、フィードバックを反映する予定である。
• 基本的にはローカル環境で動作させる方針で、外部の生成AIサービスに依存しない構成を目指している。

技術構成

• フレームワーク：Next.js、TypeScript、React
• 対応文書：PDF、Markdown、Wordファイル
• LLM：Granite 4.2 3B
• RAG方式：標準RAG、HyDE RAG
• 実行環境：ローカル環境
• Granite 4.2 3Bをデフォルトモデルに設定し、Granite 4.2シリーズを推奨モデルとして紹介した。
• 32GBメモリのPCでも動作する小規模言語モデルを利用していることが説明された。8Bモデルも候補として挙げられた。

開発プロセス

• まずChatGPTやClaudeを使って仕様書を作成し、バージョン1.0から1.6まで、合計約7回書き直した。
• 仕様書をIBM Bobに読み込ませ、プランファイルを作成してから実装を進めた。
• 実装は複数のフェーズに分け、1ステップずつ確認することで、ライブラリの見落としや不要なトークン消費を抑えた。
• 仕様書や実装プロンプトの変更履歴を残すことで、エラー発生時に原因を追跡しやすくした。

主な機能とデモ

• ログイン機能とマルチユーザー対応
• 利用者向けのガイド表示
• PDF、Markdown、Wordファイルなどのアップロード
• 文書のチャンク自動認識と手動編集
• 標準RAGとHyDE RAGの切り替え
• HyDE RAGで生成された検索用の仮想文章の確認
• 検索結果の引用元、ページ番号、類似度の表示
• ログイン・ログアウトやNotebook作成などの操作ログ
• CSRF対策やTemperatureなど、システム・生成設定の管理画面での可視化
• システム側の設定をターミナルではなく画面上で確認できるようにする工夫

質疑応答・技術ディスカッション

MQTTとIoTデバイス

• M5Stack Atom S3は、MQTTブローカーに接続したままSubscribeすることで、リアルタイムにメッセージを受信している。
• HTTPのような定期ポーリングではなく、MQTTの接続を維持する方式であることが説明された。
• ラズパイでも、Linux上に必要なソフトウェアとプログラムを用意すれば、同様の構成を実現できるとのコメントがあった。

効果音・UI実装

• QCプレイブックの効果音は、音声ファイルの配置場所、ファイル名、再生するシーンを仕様書に記載することで実装した。
• 「ピロン」「キラリーン」などの擬音を含めて指示し、具体的な音声ライブラリの選定はAIに任せた。
• 画面レイアウト、左右のメニュー、BootstrapやBootstrap Iconsの利用、アイコン名などを事前に指定すると、意図したデザインに近づけやすいという意見が出た。
• UIを後から大きく変更するとトークン消費が増えるため、画面構成は早い段階で決めておくことが重要だと確認された。

AI駆動開発に関する共通の学び

• 仕様書は単なる補足資料ではなく、AIに対する自然言語によるプログラム指示として機能する。
• 要件定義や基本設計を丁寧に行うことで、初回実装の精度が高まり、修正に伴うトークン消費を抑えられる。
• バックエンドとフロントエンドの間に仕様の抜けがあると、実装後の調整で大きな手戻りが発生する。
• 開発者の知見、技術上の制約、採用しない技術、環境変数やセキュリティ上の注意点まで仕様書に含めることが重要である。
• AIに任せる部分と、人間が設計判断を行う部分を切り分けることで、複数技術を組み合わせたプロトタイピングでも効率よく開発できるという認識が共有された。

まとめ

• 今回は、AIを活用したアプリケーション開発をテーマに、QC活動支援、Web 3D・IoT連携、自治体・教育機関向けローカルRAGという異なる事例が紹介された。
• 3つの発表に共通して、事前の仕様書作成、設計意図の明文化、開発経緯の記録が、実装の安定性とトークン消費の抑制に有効であることが示された。
• 発表後は、QCプレイブック、MQTT、Granite 4.2、UI設計、AI駆動開発の進め方について意見交換を行い、自由解散となった。