記事のサマリー（TL;DR）
- サイボウズが2026年7月17日、モバイルエンジニア20名超が参加する社内ハッカソンで Claude Code を活用した「1回限り指示」による自律アプリ開発を実施
- 各チームは仕様書・アーキテクチャ・トラブルシューティングなどのドキュメントを整備し、
startスキル1発でAIに3時間の自律開発を実行させ、全チームがアプリを完成 - マルチエージェント（PM・アーキテクト・QA・開発者・レビュアー役に分割）やペルソナ別レビュー構成など、チームごとに異なるループエンジニアリング手法が生まれた
Claude Code を活用するモバイル開発チームへの示唆
今回のハッカソンが示すのは、「AIにコードを書かせる」から「AIに開発プロセス全体を回させる」フェーズへの移行が現場レベルで始まっているという事実です。サイボウズの報告では、半年前はAIエージェントへのコード生成委託が浸透していなかったのに対し、今回はループエンジニアリングの設計力がエンジニア間で差異化要因になっていると指摘されています。
日本国内でも Claude Code を業務開発に導入している開発チームは増えつつありますが、「1回のプロンプトで動くものを完成させるためにドキュメントをどう整備するか」という観点は、kintone や Salesforce と接続するカスタムUI開発や、Shopify Plus の Checkout 拡張開発など、仕様が複雑なプロジェクトで特に有効です。AIへのワンショット指示が成立するかどうかは、プロンプトの質より先に「ドキュメントの質」で決まる——これが今回のハッカソンから得られる最も実践的な知見です。
詳細
モバイルまつりとは
「モバイルまつり」は、サイボウズのモバイルエンジニアがプロダクトチームの枠を超えてオフラインで集まる社内コミュニティイベントです。普段はリモートワーク中心のメンバーが一堂に会し、アプリ開発の課題を議論したり、最近の業務や興味のある技術について話したりすることで、信頼関係を築く場として機能しています。
今回は全国から20名超のモバイルエンジニアが東京オフィスに集合し、以下のコンテンツで濃密な1日を過ごしました。
| コンテンツ | 内容 |
|---|---|
| アイスブレイク | 「私は誰でしょう」クイズ |
| マネージャートーク | モバイルエンジニアの活動・方針説明 |
| ランチ | お弁当を食べながら歓談 |
| AIハッカソン | 今回のメインコンテンツ |
| リクエストLT | 指名エンジニアによる最近の業務紹介 |
| 懇親会 | 交流会 |
AIハッカソンに取り組んだ背景
モバイルエンジニアを対象にしたAIハッカソンは今回で2回目です。前回開催時はAIエージェントにコードを書かせること自体がまだ一般的ではなく、ハッカソンを通じて心理的ハードルを下げることが主目的でした。その後半年が経過し、AIにプロダクトコードを書かせること自体はチーム全体に浸透しました。
しかしAIエージェント側も進化しています。最近は「ループエンジニアリング」——AIエージェントが自律的に実装と検証を繰り返すループを設計する手法——の必要性が語られるようになっています。ただし、モバイルエンジニア間でのループエンジニアリングへの取り組み方には依然として大きなばらつきがありました。
そこで第2回ハッカソンでは、最新AIエージェントがどの程度自律的に作業をこなせるかを体感し、多くの作業をAIに委ねるためのドキュメント整備とループ設計を実際に試みる場を設けることにしました。
ハッカソン運営で工夫したこと
「ワンショット指示のみ」というルール
今回のAIハッカソンで使用したAIエージェントは Claude Code です。各チームに課したルールは「ハッカソン時間内にアプリの仕様・開発プロセスを定義するドキュメントを整備し、合図で全チーム一斉に1回だけAIに指示を出して、その後はAIの自律実行に任せる」というものでした。
運営側はAIへの1回限りの指示として、以下のstartスキル（Android用）を配布しました。
---
name: start
description: ハッカソン開始。docs/README.md を起点にアプリを自律開発する
disable-model-invocation: true
---
# アプリ開発の開始
これは1回きりの自律実行である。以下を厳守すること。
## 絶対ルール
- ユーザーへの質問は禁止。不明点はドキュメントとコードから判断し、判断に迷ったら「動くものを優先」する
- 作業を途中で止めない。完成条件を満たすまで実装・検証を繰り返す
## 手順
1. `docs/README.md` を読む。これがこのプロジェクトの開発の起点であり、他のドキュメントの構成・読む順序・開発プロセスはすべてそこに定義されている
2. `docs/README.md` の指示に従って開発を進める
- `docs` に検証方法の定義がない場合は、プロジェクト標準の方法（`./gradlew assembleDebug`）で自らビルド確認を行うこと
3. 完了後、ハッカソンの成果発表に使える資料を `PRESENTATION.html` としてプロジェクトルートに書き出す
- 単一のHTMLファイルで完結させること。CSS・JSはすべてインラインで記述し、外部ファイルやCDNへの参照は禁止
なお、Claude Code の /goal コマンドの利用はあえて避け、手作りのループエンジニアリングを試行錯誤できる余地を残しました。また、成果発表用の資料生成もスキルに組み込むことで、参加者が時間いっぱいまでアプリ開発に集中できる設計にしました。
お題
「喫茶さいぼうずのアプリを作ってください」
3〜4人チームに分かれ、約3時間でAIを最大限活用して実際に動くモバイルアプリを開発し、成果発表を行いました。
成果発表
運営側の予想を超えた多様なアプリが出来上がりました。主な成果物は以下のとおりです。
- kintone をバックエンドに使ったオンライン注文システム
- バーのマスターとの会話を楽しむアプリ
- 喫茶店経営ゲーム
- 喫茶店の常連客向けアプリ（スクリーンショット公開あり）
ハッカソン運営側は「途中でAIが止まりアプリが完成しないチームも出てくる」と予想していましたが、実際には全チームがアプリ完成まで完走しました。
各チームのAI活用アプローチ
ドキュメントを徹底整備したチーム
あるチームは、AIが自律的に動けるようにドキュメント一式を事前に整備しました。具体的には以下の内容を網羅していました。
- コンセプト
- 受け入れ条件
- アーキテクチャ
- 技術規約
- 開発工程の定義
- シミュレータによる確認方法
- トラブルシューティング
docs/README.md には各ドキュメントを読み込むタイミングを明示し、完成の定義や制限時間まで改善を続けるための指示も記述することで、AIが自律的にアプリの完成度を上げ続けられる構造にしていました。
仕様もAIに考えさせたチーム（マルチエージェント構成）
別のチームは docs/README.md にはお題と使用するスキル・サブエージェントの指定のみを書き、仕様の策定からAIに委ねる構成を取りました。
実際の開発フローは次のとおりです。
- **メインエージェント（開発マネージャー役）**が全体を統括
- プロダクトマネージャーエージェントを起動して仕様を策定
- アーキテクトエージェントに設計を担当させる
- QAエージェントと開発者エージェントがTDDで実装
- レビューエージェントがコードレビューを実施
人間のソフトウェア開発チームの役割分担を、そのままサブエージェント構成に落とし込んだ事例です。
ペルソナ別レビューを取り入れたチーム
さらに別のチームは、複数のペルソナを定義してそれぞれにサブエージェントを割り当て、実装したアプリをレビューさせました。
- プロダクトマネージャーペルソナ：機能面の評価
- ユーザーペルソナ：受け入れ基準の評価
- エンジニアペルソナ：実現可能性の評価
ペルソナごとに評価軸を分けるだけでなく、誰が最終決定権を持つかを明確に定義した点が特徴的で、AIレビューの意思決定構造として参考になります。
振り返りと今後
今回のハッカソンは新規アプリ開発という、AIにとって比較的取り組みやすい課題だったという点は留意が必要です。大規模な既存コードを変更するケースで同じように完走できるかは、また別の検証が必要です。
それでも、ループエンジニアリングを実際に体験し「思ったよりも使えるな」と感じたメンバーが多かったと報告されています。また、共通のお題で複数チームが取り組んだことで、自分では思いつかなかったAI活用手法をチーム間で学び合える場にもなりました。
サイボウズのモバイルエンジニアリング組織は、AIの発展によってここ1〜2年でエンジニアの貢献スタイルが大きく変化しており、今後もその変化は継続するという認識を持ちながら、コミュニティ単位での継続的な技術アップデートを進めています。