こんにちは、Algomatic の広報担当です。
「LLM プロダクトの品質はどう担保するか」「AI 駆動開発の設計環境をどう整えるか」「コストと品質のトレードオフにどう向き合うか」—— AI を実業務に組み込んでいると、こうした問いに日々向き合うことになりますよね。
弊社のエンジニアたちも、各自の現場でこれらの問いと格闘しています。先日開催した社内エンジニア LT 会 「わいわいLT会」 特別回では、その試行錯誤の過程と得られた知見が共有されました。今回はその発表の様子を一部紹介します。
なお今回は 「発表スライドをすべて AI で生成する」 という縛りを設け、知見の内容だけでなく、AI を使った発表準備のワークフローそのものも共有できる場としました。
本記事の後半には、各メンバーの資料作成の概要も載せているので、ぜひご覧ください！
なぜ「AI 生成スライド限定」で開催したか
Algomatic では「プロダクトわいわいシェア会」と呼ばれる社内 LT 会を不定期で開催しています。カンパニー制という組織形態上、知見が各カンパニーに閉じやすいという課題があり、横断的な知見共有の場として継続的に実施してきました。
今回の特別ルールには、以下の狙いがありました。
1. スライド作成工程そのものをAIに委譲する取り組みを検証する。発表内容の準備だけでなく、スライドのデザイン・レイアウトまで AI に任せることで、どこまで人の手を離せるかを検証する。
2. AI 活用の「仕込みの差」を可視化する。同じ「AI 生成スライド」でも、各人のワークフロー・ツール選定・工夫のポイントは大きく異なる。その差分こそが知見になる。
3. スライド生成のワークフロー自体をチームの資産にする。各自が試行錯誤したプロンプト・ツール構成・QA ループの一部は、チームの知見として蓄積し、再利用・改善できるリソースとして活用する。「発表して終わり」ではなく、発表資料の生成過程そのものを共有財産にする。
開催概要
| 発表者 | カンパニー | タイトル |
|---|---|---|
| 坂本 | Algomatic Works | スマホで開発業務は完結するか |
| 岩城 | AI Transformation | 新規事業 × 大規模SaaS開発における AI駆動開発の実践 |
| 宮脇 | Algomatic Works | LLM プロダクトの品質管理 |
| 小石 | Algomatic Works | Claude Codeを使い始めて変わったこと |
| 藤崎 | AI Transformation | CE自動化とリアルタイムAI統合の実装詳解 |
| 末國 | ネオセールス | 情熱1to1 |
AI ツールの比較検証、AI 駆動開発の設計環境、LLM プロダクトの品質管理、コスト最適化…… それぞれ異なる角度から、「AIと共に開発する現場の苦労や知見」 が語られました。
以下ではその一部について紹介いたしますが、事業に関する内容は省略しています。
坂本 - スマホで開発業務は完結するか
Algomatic Works のテックリードである坂本からは、折りたたみスマホ×AIツールで 「スマホだけで開発業務を完結できるか」 を検証した結果が共有されました。
- Android Linux 運用: スマホ上で Linux ターミナルを起動することは技術的に可能だが、セットアップの煩雑さと実用性の低さから断念
- Devin: Slack 経由でタスクを指示し、AI が自律的にコーディング・PR 作成まで行う。$500/月〜という価格が個人利用のハードルになる
- GitHub Copilot（Web）: ブラウザから利用可能。追加コストが少ない一方、複雑なタスクへの対応力と自律性は限定的（MCP 非対応で外部連携も不可）
- Claude Code: アプリからターミナル操作や、Slack でのチャット感覚開発が可能。ただし従量課金でコストが読みづらかったり、PRを自動で出せない
上記のアプローチを検証したものの、いずれも「いいとこはあるものの、いずれも限定的であった」と言います。 そんななか、満を持して登場したのが Claude Code Remote Control です。これはスマホアプリからローカル PC を操作し、MCP を介した本格的な開発が可能にするツールです。
最終的に最も実用的だったのが Claude Code Remote Control + Linear MCP の組み合わせ だそうで、スマホからタスク番号を指示するだけで、チケット内容の自動取得・コード実装・PR 作成まで一気通貫で完結する仕組みについて紹介しました。
岩城 - 新規事業 × 大規模SaaS開発における AI駆動開発の実践
AI Transformation 事業部のAIエンジニアである岩城からは、新規事業として大規模 SaaS を開発する中で実践した AI 駆動開発の知見 について共有がありました。
大規模 SaaS における AI 駆動開発の難しさは、相反する 3 つの要求を同時に満たす必要がある点にあるといいます。
AIコーディングを用いたコード生成は、開発を加速させる一方で、出力の揺らぎ や 局所最適な実装の積み上がり、悪いコードの増殖 という問題も抱えています。
そこで辿り着いた方針は 「AIを賢くするのではなく、AIが壊せない環境を作る」 というものでした。アーキテクチャと設計方針を先に固め、「人の記憶」ではなく「環境」に設計を保持することで、アーキテクチャと設計方針を先に固め、「人の記憶」ではなく「環境」に設計を保持することで、AI がコードを生成するたびに設計原則に引き戻される構造を作りました。
また設計においては、カスタマイズと標準化のバランスを取ることも重要なポイントとなります。このポイントをAI駆動開発に落とし込む際は、固定化ではなく揺らぎを前提とした設計環境を作ること、すなわち開発ストリームの分離が重要であるとのことです。
宮脇 - LLM プロダクトの品質管理 — 実践と学び
Algomatic Works のAIエンジニアである宮脇からは、LLMを使った タスク指向対話による情報収集システムの開発・運用から得られた品質管理の知見 について発表がありました。
自然言語での対話による情報収集はフォーム形式より自由度が高い一方で、対話というタスクの性質にはステートフル性やモデルの非決定性など、構造的な難しさを伴います。
こうした難しさに対処するために、2つのアプローチに取り組んだといいます。
1. エージェント分割による LLM 依存の局所化 初めは1 つのプロンプトで対話の全制御を行っており、指示の競合により「聞き漏らし」や「中断」が頻発していたそうです。 これに対して、タスクシナリオの意味的なチャンクごとにエージェントを分割し、LLM の判断範囲を限定することで、エラー率を大幅に軽減したそうです。
2. テストドリブンな評価ループの構築 また E2E テストを実施していたものの、運用中は潜在的なエラーケースに悩まされていたと言います。 これに対して、シナリオを条件網羅した190件のステートレスな単体テストとフィールド単位の抽出精度評価を組み合わせる体制を構築、これにより潜在的なエラーケースを大量に特定できたそうです。
発表のまとめとして 「LLMシステム開発は従来のソフトウェア開発と変わらない」とし、以下の学びを共有しました。
- 評価の役割分担を明確にする: 「シナリオ（仕様）」「プロンプト（実装）」「テストセット（防止）」「チェッカー（検知）」の役割を分ける
- 最終判断は静的ロジックへ: LLM には根拠となるシグナルを出力させ、最終的な合否判定は静的なプログラムで行う
- ステートレスなテスト: 対話状態をモックで注入することで、複雑なシナリオを切り離してテスト可能にする
小石 - Claude Codeを使い始めて変わったこと
Algomatic Works の Webエンジニアである小石からは、Claude Code を使い始めてから開発の進め方がどう変わったか について発表がありました。
現在は、1リポジトリに Worktree を 3つ用意し、重めの機能開発・並行タスク・細かいタスクを同時に走らせているといいます。Claude Code は非同期で動かせるので、待ち時間がそのまま別のタスクに使えるわけです。
現在の開発フローについては、以下のような流れで実装することが多いといい、使い始めて分かったことについても共有がありました。
ただ今後の課題として、速く作れるようになった分、仕様の考慮漏れが増えたという新しい問題も出てきたそうです。対策としては様々考えられますが、実装に入る前に仕様書をAIと壁打ちして考慮事項を洗い出すようにしたところ、10 件以上の見落としを事前に防げるようになったとのことでした。
藤崎 - コンテキストエンジニアリング自動化とリアルタイムAI統合の実装詳解
AI Transformation 事業部のAIエンジニアである藤崎からは、事業部で取り組んでいる AI 活用の実践知 について2つのテーマが共有されました。
1 つ目は「AI に雑務を任せるためのコンテキストエンジニアリング自動化」です。タスクの管理について、その実行データを知識ストアに変換してフィードバックする仕組みを構築し、AI が OJT のように自己成長できる設計を模索していました。タスク単位を複数のステップに分離し、各ステップでツールを厳密に制御することでコンテキスト汚染を防ぐ点が設計の核心です。
2 つ目は「AI とリアルタイムで連動する UI のアーキテクチャ設計」です。WebSocket も Streaming API も使わず、DB をキューとしてポーリングするだけのシンプルな設計で AI↔UI 間の非同期ギャップを吸収しています。AIもユーザーも同じコマンドパスを通ることで整合性の保証をシンプルにしていました（詳細は省きます）。
末國 - 情熱1to1 — LLM 生成コンテンツを本番で動かす
ネオセールス AIエンジニアである末國からは、LLM を用いて大量のパーソナライズ文章を本番環境で生成・運用する中で直面した4つの課題と解決策 について共有がありました。「間違った内容を出力すると即インシデント」という高い正確性が求められる環境での知見は、LLM プロダクト開発全般に応用できる内容でした。
1. ドメインエキスパートの思考過程の言語化 エンジニアだけでは判断できない品質基準を定義するため、ドメインエキスパートの思考過程を言語化したそうです。「成果物」ではなく「どう考えたか」を引き出すことがポイントで、その思考ステップがそのままプロンプト設計に反映されました。
2. オブザーバビリティの確保 大規模なスケールにあたり、Langfuse を導入して LLM の推論過程をすべて可視化したそうです。「どこで品質が崩れたか」をステップ単位で追跡できる体制を整えることで、改善サイクルが回るようになったといいます。
3. 自動ファクトチェックパイプライン 人力チェックから始まり、LLM による自動ファクトチェックへ段階的に移行しました。文章中の記述を「事実（fact）」「仮説（hypothesis）」「レトリック」に分類し、ソースに基づいた 4 段階判定（EXPLICIT / INFERRED / UNKNOWN / MISREAD）を行うことで正確性を担保しています。
4. 品質を下げないコスト最適化 コスト削減の本質は「安いモデルを使うこと」ではなく「推論が要らないほどタスクを分解すること」にあるという洞察が共有されました。複雑な処理を「要約」「アウトライン」「本文生成」の 3 ステップに分解し、軽量なモデルでも正確に動くワークフローへ刷新しました。
ただし、タスクに取り組む際は「まず品質の天井を確認して、その後にコスト最適化を行うべき」だといいます。最初からコストをケチると何が可能かの基準が作れなくなる という言葉はその通りだと感じました。
スライドの作り方
今回のもう一つのテーマは「スライドそのものをどうAIで作ったか」でした。各発表者、いろんな手法で AI 生成スライドを仕上げていましたので一部ご紹介します。
| 発表者 | スライドツール |
|---|---|
| 坂本 | Claude Code |
| 岩城 | Claude Code + reveal.js（decktape で PDF 変換・PNG 検証ループ） |
| 宮脇 | Claude + Marp + NotebookLM + Nano Banana 2 |
| 小石 | Claude Code + Slidev |
| 藤崎 | Claude Code + Slidev（デモ動画も Playwright + FFmpeg で全自動） |
| 末國 | Claude Code + visua-explainer |
岩城 - Claude Code + reveal.js + decktape
Claude Code を核に、HTML + CSS ベースのスライド（reveal.js）を生成し、decktape で PDF に変換するワークフローを組み込んでいました。 **全操作の 25% がスクリーンショット確認だそうで、「視覚的な品質確認まで AI のワークフローに組み込む」というアプローチが重要だったといいます。
宮脇 - Claude + marp + Nodebook LM + Nano Banana 2
宮脇は、Nano Banana 2 を用いた画像生成のアプローチでスライドを作成していました。 プロジェクトに関する取り組みは Claude との対話によって深掘りを行い、rules と組み合わせてデザインガイドとページごとの構成を作成したのち、マルチターンの画像編集を行っていました。
またスライド内のイラストについては、Notebook LM の方が優れていたため、これを参照させて編集を行なったそうです。
藤崎 - Claude Code + Slidev + Playwright + FFmpeg（全自動）
藤崎は、スライドだけでなく、UIのデモ動画も Claude Code で全自動生成していました。スライド作成に要した時間は2時間程度だそうで、参加者一同驚いておりました。
具体的には、以下のような方法でスライドとデモ動画を作成していました。
まとめ
各参加者において、共通していたのは 「AI をどう使うか」ではなく「AI がうまく動ける環境をどう作るか」 という点でした。それぞれ視点は違いましたが、AIの出力をそのまま信頼するのではなく、AI が正しい方向に動きやすい仕組みを設計することが、実用レベルの AI 活用の核心だという共通認識が見えました。
また各自のワークフロー（ツール選定・プロンプト設計・Visual QA の方法）の差分が、そのまま知見として共有できたことも収穫でした。藤崎のようにデモ動画の生成まで全自動化した事例は、「資料を作る」という行為自体がこれからどう変わるかを示す具体的なアウトプットになりました。
Algomatic では引き続き、このような技術知見を横断的に共有する場を設けていきます。
おわりに
Algomatic では、「AI革命で人々を幸せにする」をミッションに、LLM・AI エージェントをはじめとする最先端技術を実業務に組み込んでいくエンジニアを募集しています。今回紹介したような実践的な AI 活用知見を、日々の開発の中で積み上げ・共有し合える環境に興味を持っていただけましたら、ぜひお気軽にお話ししましょう！
カジュアル面談のお申し込みはこちらです↓
