ドキュメント整備をDevinに任せたら、4週間分の作業が6時間のレビューで完了した話

はじめに

弊社エスマットでのファームウェア開発において、しばらく悩まされていた課題だった技術ドキュメントの整備を AI エージェントの Devin に任せてみました。

結果として、人手で 4 週間と見積もられた作業が、わずか 6 時間のレビュー作業で完了。合計で 1 万行を超える Markdown ドキュメントが作成され、ファームウェアの理解促進と AI コーディング精度の向上という目標を実現できそうなところまできました。

この記事では、Devin を活用したドキュメント整備の具体的なアプローチと、実際の運用で得られたノウハウを共有します。

背景：散在・陳腐化したファームウェアドキュメントの課題

ドキュメントの現状と課題

弊社製品であるスマートマットのファームウェアは、元々外注先で開発されたものを引き継いで開発を続けていました。外注先から引き継いだ時点で体系的なドキュメントは無かったようで、弊社内で変更開発をするタイミングなど都度都度ドキュメントの作成をしていました。そのため以下のような課題を抱えていました：

• ドキュメントの散在: 社内Wikiにナレッジが点在
• 情報の陳腐化: 変更開発時の部分的な記録のみ存在し、古い情報が残っている
• 網羅性の不足: システム全体を俯瞰できるドキュメントがない
• 検索性の悪さ: 体系的に整理されておらず、必要な情報を見つけるのに時間がかかる

解決の必要性

これらの課題により、以下の問題が発生していました：

• 他のエンジニアがファームウェアを理解しづらい
• 新メンバーの学習コストが高い
• AI コーディングの精度が低い: AI が参照できる情報が不足

特に最後の点は重要で、社内で AI コーディングに積極的に取り組む中で、AI がコードを理解し適切な提案をするためには、リポジトリ内に体系的なドキュメントが必要だと痛感していました。

なぜ Devin を選んだのか

選定理由

1. 社内環境の整備: 既に Devin を使える環境があり、過去の使用経験もあった
2. 高い自律性: 会議など他の予定の合間に、自立的に作業を進められる

具体的なアプローチ：Issue 駆動でのドキュメント整備

作業フローの設計

Devin との協働方法を決めるにあたり、まず Devin 自身にどのようなドキュメントが不足しているかを洗い出してもらい、その後の最適なアプローチが何かを相談しました。

当初は「見出しだけ用意してもらって、内容は人間が書く」ことも検討しましたが、Devin からは以下の提案がありました：

わからないところは質問するので、基本的には Devin 主導でプルリクエストまで完成させられる

この提案により、以下のワークフローで進めることに決めました：

実際の作業手順

1. 課題の洗い出し: Devin に不足ドキュメントのリストアップと優先順位付けを依頼
2. Issue 化: 洗い出された課題を GitHub Issue として登録
3. 順次対応: 「Issue 番号 XX を対応して」という簡潔な指示で作業開始
4. 自律的な実行: Devin が Slack 連携で質問しながら、プルリクエストまで完成
5. レビュー & マージ: 人間はレビューに専念

Slack 連携の活用

Devin は Slack 連携機能により、判断が必要な場面で適宜質問してくれます。これにより、人間は張り付いて監視する必要がなく、他の業務と並行して進められます。
（実際のところ、今回取り組んだ範囲では質問は飛んできませんでした。）

Slackでのやり取りの様子

実施内容と成果

作成された成果物

• Issue 総数: 12 件
• 完了済み: 6 件
• ドキュメント量: Markdown で約 1 万行
• 工数削減効果: 4 週間分の作業を 6 時間のレビューで完了

登録されたIssue

特に評価の高かったドキュメント

開発フレームワークの情報だけから、環境構築方法やビルド方法のドキュメントを自動生成してくれた点が印象的でした。

実際の開発では VS Code 拡張を使用していますが、CLI ベースの開発環境の構築方法と開発方法が記載されました。これは実態とは異なりますが AI 自身による開発にはCLIベースの方が適していると考えて、そのまま採用することにしました。

Devin との協働で得られたノウハウ

効果的な指示の出し方

• シンプルな指示: Issueがしっかりかけていれば、「Issue XX を対応して」程度の簡潔な指示で十分
• Devin の提案を聞く: 作業方針に迷ったら、Devin 自身に最適なアプローチを相談

レビュー作業のポイント

1回のプルリクエストで千行から二千行の変更がありました。

大量のドキュメントを精読するのは現実的ではないため、以下の観点でレビューを実施：

• 明らかな間違い: ソースコードを参照しているため、大きな間違いは少ない
• 記述レベル: 詳細すぎる説明を記載する傾向にあったため、記述レベルが適切かを確認した
• 全体の構成: 章立てや内容のバランス

課題と改善点

期待と異なった部分

細かすぎる記述傾向

Devin は関数内部のフローまで詳細に記述する傾向がありました。「ソースを見ればわかることは記載不要」という指摘により修正してもらいました。

以下のスクリーンショットのようにプルリクエストにコメントを書けば、Devinがコメントを確認して修正をしてくれます。（質問にだけ答えてとお願いしたのに勝手に修正しちゃうのはご愛嬌）

Devinに指摘する様子

Devinがコメントする様子

人手での修正は不要

1つのIssueを対応するのに多くの質問が飛んできたり、人手でドキュメントを埋める必要があるだろうと考えていましたが、その想像は良い意味で外れました。
質問をされることなくプルリクエストを出すところまでDevinが自律的に進められました。
また、プルリクエストのコメント機能を活用することで、Devin に修正依頼を出せるため、人間が直接ドキュメントを編集する必要はありませんでした。

残課題のある Issue

以下の Issue は人間の判断が必要そうな内容のため、完全自動化は難しいと予想：

• テスト戦略・手順書の作成: 戦略的判断が必要
• 工場生産時に使う機能に関するドキュメント: 外部プロセスの理解が必要

Devinがどこまでできるか、どのくらい手助けが必要なのか、今後試してみたいと思います。

今後の展開と他チームへのアドバイス

他プロジェクトへの応用

このアプローチは「AI に Issue を登録させ、後続の AI に順次対応させる」という汎用的な手法として活用できます。

社内の他メンバーは既に、複数の Issue を AI に並列で対応させる運用も始めています。

同じ課題を持つチームへのアドバイス

1. 一歩踏み出す: ドキュメント整備は後回しにするほど手をつけづらくなる。AI の力を借りて始めよう
2. Issue 駆動アプローチ: ドキュメント整備以外でも、Issue 化による段階的なタスク管理は有効
3. 自立型 AI エージェントの活用: やることが明確なタスクでは、監視不要で作業が進む

まとめ

Devin を活用したファームウェアドキュメント整備により、以下の成果を得られました：

• 大幅な工数削減: 4 週間 → 6 時間のレビューで完了
• 高品質なドキュメント: 1 万行の体系的な Markdown ドキュメント
• AI コーディング環境の改善: リポジトリ内ドキュメントによる AI 精度向上

今回重視したのは、体系的に網羅されたドキュメントを作り切ることです。
Issue 駆動のアプローチにより、大規模なドキュメント整備も管理可能なタスクに分割できます。まずは体系的にドキュメントを作り切って、あとは間違いを見つけた時やコード変更をしたときに同じようにドキュメント整備をAIにさせたいと考えています。このようにAIによるドキュメント整備のループを回して質の高いドキュメントへ進化・保守させていこうと考えています。

技術ドキュメント整備でお困りの方は、ぜひこのアプローチを試してみてください。