Devinまとめ - kocya-dev/note GitHub Wiki

Devinの活用事例と使い方のポイント - 実践知見まとめ

1. 実際の利用スタイルと働き方

柔軟な作業環境

  • スマホからSlackで指示を出せるため「ながら開発」が可能
  • 昼休憩やトイレに行く前に依頼しておく新しい働き方
  • 子育てや家事をしながらでも開発作業を進められる

「別の人に頼む」感覚

  • セッション間のDevinの履歴は共有されない（各セッションは独立）
  • 100件、200件の依頼も並列で処理可能
  • 「違う人に頼む」感覚で使うと効果的

サイボウズの先行事例

  • サイボウズでは2023年12月から「社員の一人」としてAIエージェントを運用
  • Devinの登場で「AIと共に働く未来」についての言語化が進んだ

2. コードベースとの関わり方

既存コードへの対応

  • 「どこかにこういうコードがあるはずなんだけど」と頼むとリポジトリを調査してレポートを生成
  • 0→1より1→10、さらには1→100の作業に価値を発揮
  • 既存コードベースでも効果を発揮するが、ドキュメントやナレッジの整備は必要

コードの民主化

  • 「ソースコードをいじれる人が増えた」という効果
  • デザイナーが気づいた文言修正/画面修正を自身で行えるように
  • 「どこをいじればいいか」「Pull Requestの出し方」を知らなくても指示可能

3. 運用テクニック

タスク分割の重要性

  • 10ACU超えそうならPRに現状を書き、次のセッションに引き継ぐ
  • 「小さく頼む。大きく頼むと4万溶かす」（実例あり）
  • 「雑に頼むと素朴な方法で解決しようとする」

スキル習得

  • 「頼む人間のスキルを上げる」「雑なものを投げて、失敗を見る」
  • 「使いこなせる人はまともなこと以外の頼み事もいっぱい試している」
  • 「お手本見せるといい感じにやってくれる」

セキュリティ対策

  • Devinが扱うものはプライベートリポジトリに限定
  • パブリックなリポジトリも必要に応じてフォークしてプライベート環境で使用
  • コアなロジックやクレデンシャル/データアクセスはスコープアウト

4. 導入形態と考え方

全社的な活用パターン

  • Ubie社：「手を上げた人全員使える仕組み」→コードの民主化促進
  • Helpfeel社：「コストに責任を持ったマネージャー層に限定」→リスク管理

コスト構造の特徴

  • ユーザー数ではなく使用量（ACU）による課金
  • 思想的には「ひとつの組織で働くDevin」として育てるのが効果的
  • 複数組織で使う場合はDevin自体を分ける方が効果的

5. ユーザー体験の特徴

AIエージェントとしての特性

  • 「ITに明るい大学生みたいな所作」で「一周回って可愛らしい」
  • 「若い人に仕事を頼む感覚」で使える
  • 「労基法が適用されない社員」「退職しない」という特性

ユースケース開拓

  • 自社サービスのユーザーテスト（「知識のないユーザーを無限に召喚」可能）
  • 個人開発のハードル低下と試行回数の増加
  • 技術検証の効率化

働き方への影響

  • オフショア・SES会社への影響の可能性
  • 「どの人を選ぶ採用コスト」ゼロで「何人でも並列起動」可能に
  • 「プロジェクトの繁閑に応じて」スケールアウト・インの実現

Devinをはじめとするプログラミング用AIエージェントは、単なるコーディング支援ツールではなく、「チームの新しいメンバー」として組織に溶け込み、開発プロセスや働き方そのものを変える可能性を秘めています。

https://qiita.com/Satoshi_Numasawa/items/2a4067bbb3b20864c397 https://note.com/teramotodaiki/n/n349d1d361804 https://note.com/morioki_3/n/n8a94dc95dde8 https://zenn.dev/paiza/articles/introducing-devin https://zenn.dev/smartround_dev/articles/cd6c1e168b4f79 https://zenn.dev/cureapp/articles/75b405a89068df https://zenn.dev/nemunyan/articles/cf3b7fefd7536b https://zenn.dev/hand_dot/articles/38f5bfaf80aab5

Devinを有効に活用するために守るべきポイント

  1. 利用者のスキル
  • a
    • プログラミングの基礎知識: Devinは自律的にコーディングを行うことができますが、利用者がプログラミングの基本的な概念や用語を理解していることで、Devinの提案や実行内容をより深く理解し、適切な指示やフィードバックを与えることができます。
    • 問題解決能力: Devinに複雑なタスクを依頼する場合、利用者は問題をより小さな単位に分割したり、Devinが出した結果を評価したりする能力が求められます。
    • コミュニケーション能力: Devinとのコミュニケーションは、タスクの意図を正確に伝え、期待する成果を得るために重要です。明確かつ具体的な指示を出すスキルが求められます。
    • 学習意欲: AI技術は日々進化しているため、Devinの新しい機能や最適な使い方を継続的に学習する意欲が重要です。
    • マネジメントスキル: Devinにタスクを与える際には、明確な指示と適切な裁量を与えることが重要です。Devinの特性を理解し、チーム全体の最適化を考慮したマネジメントが必要です。
  • b
    • プログラミング知識の欠如: プログラミングの基礎知識がないままDevinに丸投げすることは避けるべきです。Devinの提案や実行内容を理解できず、誤った方向に進む可能性や、セキュリティ上のリスクを見逃す可能性があります。
    • 問題解決をDevinに依存しすぎる: 複雑な問題を自ら分析・分解する努力を怠り、Devinに全てを任せることは避けるべきです。Devinはあくまでツールであり、人間の思考や判断を完全に代替できるわけではありません。
    • コミュニケーション不足: Devinの質問や提案に対して適切なフィードバックを怠ったり、意図を曖昧なまま伝えたりすることは避けるべきです。効果的な連携のためには、明確なコミュニケーションが不可欠です。
    • 学習意欲の欠如: Devinの進化や最適な使い方を学ぼうとしない姿勢は、ツールの潜在能力を十分に引き出せない原因となります。
    • AIへの過度な依存: Devinに頼りすぎることで、利用者自身のプログラミングスキルや問題解決能力が低下するリスクがあります。特に学習段階のプログラマーがAI生成コードを理解せずに使用すると、スキル向上が阻害されます。
    • 基礎知識不足: プログラミングや開発環境に関する基礎知識が不足していると、Devinが生成したコードや提案を正しく評価できず、不適切な結果を招く可能性があります。
  1. 利用者の使い方
  • a
    • 役割分担: 「0→1は人間、1→10はDevinに任せる」という役割分担が有効です。新規機能のアイデア出しや設計は人間が行い、その後の実装やテストをDevinに任せることで、効率的な開発が可能です。
    • タスク分割: タスクを適切に分割し、Devinに指示を出すことが重要です。タスクが大きすぎると、Devinが途中で迷子になったり、期待通りの結果が得られない場合があります。
    • 段階的な指示と確認: Devinに指示を出す際は、段階的に指示を出し、結果を確認しながら進めることが推奨されます。これにより、Devinの誤りを早期に発見し、修正することができます。
    • プロンプト設計: 効果的なプロンプトを設計することが重要です。Devinに明確な指示を出すことで、期待通りの結果を得ることができます。
    • 明確で具体的な指示: Devinにタスクを与える際は、目的、期待する結果、必要な情報（既存のコード、ドキュメントへのリンクなど）を明確かつ具体的に伝えることが重要です。
    • 適切な粒度のタスク分割: 大きすぎるタスクはDevinが途中で混乱したり、意図しない方向に進む可能性があります。タスクを小さく分割し、段階的に依頼することで、よりスムーズな連携が期待できます。必要に応じて、大きなタスクの分割をDevin自身に依頼することも有効です。 こまめな進捗確認とフィードバック: Devinの作業中は定期的に進捗を確認し、必要に応じてフィードバックを行うことで、手戻りを防ぎ、より良い成果に繋げることができます。
    • 対話的なコミュニケーション: Devinに対して「なぜこの実装方法を選んだのか」「XXの部分で困っていることはないか」といった具体的な質問をすることで、より深い理解や問題解決に繋がる可能性があります。
    • 試行錯誤の精神: Devinはまだ発展途上のツールであるため、様々な指示やタスクを試してみて、Devinの得意なこと、苦手なことを理解することが重要です。 セッションの管理: 長時間同じセッションで作業を続けると、履歴が肥大化し、Devinの動作が不安定になる可能性があります。必要に応じて新しいセッションを開始することも検討しましょう。
    • 知識の蓄積: Devinに学習したことや重要な決定事項をメモさせることで、今後の作業に役立てることができます。
  • b
    • 曖昧で抽象的な指示: 「〇〇を作って」「△△を修正して」といった曖昧な指示は、Devinが意図を正しく理解できず、期待外れの結果に繋がる可能性が高いため避けるべきです。
    • 大きすぎるタスクの一括依頼: 大規模で複雑なタスクを分割せずにDevinに一度に依頼することは、Devinが処理しきれず、エラーや意図しない動作を引き起こす可能性があるため避けるべきです。
    • 進捗確認とフィードバックの怠り: Devinの作業状況を全く確認せず、完了報告だけを待つのは避けるべきです。早期に問題点を発見し、軌道修正するために、こまめな進捗確認とフィードバックが重要です。
    • ブラックボックスとしての利用: Devinの提案や実行内容を理解しようとせず、ブラックボックスとして盲目的に受け入れることは、誤った実装やセキュリティリスクを見過ごす原因となるため避けるべきです。
    • 試行錯誤を恐れる: Devinの様々な機能を試したり、異なる指示を与えたりすることを恐れ、決められた使い方しかしないのは、Devinの可能性を狭めることに繋がります。
    • 不要なセッションの放置: 長時間使用しないセッションを放置すると、リソースを無駄に消費したり、混乱の原因になったりする可能性があるため避けるべきです。
    • 重要な情報の安易な共有: 機密情報や重要なコードなどを安易にDevinに共有することは、情報漏洩のリスクを高める可能性があるため避けるべきです。
    • 長期的記憶への期待: Devinは長期的な記憶が苦手です。以前提供した情報を忘れることがあるため、それを前提に運用しないと効率が落ちます
    • 計画と異なる実装への放置: Devinが計画と異なる実装を繰り返す場合、その理由を明確にさせず放置すると、進行が停滞します
  1. Devinにまかせるタスクの種類
  • 得意なタスク:
    • 小規模なタスクの並行処理
    • 明確に定義された作業（明確な開始点、終了点、成功基準があるタスク）
    • 既存のパターンやコードベースに従った実装
    • リファクタリング
    • バグ修正
    • フロントエンドの修正
    • 簡単な機能実装
    • 社内ツールの構築
    • 反復的なタスク: Devinは反復的なタスクや単純なタスクに向いています。例えば、テストコードの作成、ドキュメントの作成、リファクタリングなどが挙げられます。
    • 既存コードの修正: Devinは既存コードの修正やバグ修正にも役立ちます。ただし、複雑な修正や大規模なリファクタリングは、人間のエンジニアが担当する方が良い場合があります。
    • プロトタイプ開発: Devinはプロトタイプ開発にも適しています。短期間でアイデアを形にするために、Devinを活用することができます。
    • マニュアル整備: Devinはマニュアル整備にも活用できます。技術的なドキュメントの作成や更新をDevinに任せることで、エンジニアの負担を軽減できます。
  • 注意が必要なタスク:
    • 曖昧な要件のタスク: 要件が曖昧で、人間でも判断に迷うようなタスクをDevinに丸投げすることは避けるべきです。Devinは明確な指示に基づいて動作するため、曖昧な要件では期待通りの結果を得られない可能性が高いです。
    • 高度な専門知識や創造性が求められるタスク: 特定の分野における深い専門知識や、独創的なアイデアが求められるタスクは、現時点ではDevinの得意とするところではありません。人間の専門家と連携して進めるべきです。
    • 倫理的な判断が伴うタスク: 倫理的な考慮が必要となるタスクをDevinに完全に任せることは、予期せぬ問題を引き起こす可能性があるため避けるべきです。最終的な判断は人間が行うべきです。
    • リアルタイム性や高いパフォーマンスが求められるクリティカルなタスク: 極めて高いリアルタイム性やパフォーマンスが要求されるシステムの中核部分の開発をDevinに全面的に任せることは、慎重に行うべきです。
    • 未確立な技術や環境での開発: まだ技術的な知見が少ない分野や、 нестабильном な環境での開発をDevinに全面的に任せることは、予期せぬ問題に適切に対応できない可能性があるため避けるべきです。
    • 曖昧な指示や要件のタスク
    • 大規模で複雑な機能開発（分割して依頼することが推奨されます）
    • 高度な専門知識や創造性が求められるタスク
    • 性能最適化のような時間のかかるタスク（初期段階では不向きな可能性があります）
    • 創造性や戦略的判断: Devinは創造性やビジネス戦略的な判断には不向きです。これらは人間が担当すべき領域であり、Devinに任せると期待外れの結果になる可能性があります
    • 複雑なアルゴリズム: Devinは非常に複雑なアルゴリズムや特殊環境でのみ動作するコードには対応しきれない場合があります。このようなタスクは人間が担当するべきです。
    • 認証やセキュリティ関連: Devin単体では認証やセキュリティ関連のタスクを十分に処理できません。これらは慎重に人間が管理する必要があります。
  1. その他の観点
  • a
    • セキュリティ: Devinに機密情報を渡さないようにすることが重要です。Devin専用のサンドボックス環境を用意し、セキュリティリスクを低減する必要があります。
    • コスト管理: Devinの利用料金は従量課金制であるため、コスト管理が重要です。長時間セッションや不必要なタスクを避け、効率的な利用を心がける必要があります。[記事2]
    • コードレビュー: Devinが生成したコードは、必ず人間のエンジニアがレビューする必要があります。AIが生成したコードには、バグやセキュリティ上の脆弱性が含まれている可能性があるため、注意が必要です。
    • チームのルール: チームに暗黙的なルールが存在する場合、Devinはそれを理解できません。Devinにタスクを与える前に、チームのルールを明文化し、Devinに指示する必要があります。
    • ツールの理解: Devinの機能（エージェントの種類、利用可能なツールなど）を理解することで、より効果的にタスクを依頼できます。
    • 費用対効果: Devinの利用料金を考慮し、Devinに依頼することで得られる時間や品質の向上と費用を比較検討することが重要です。
    • セキュリティとプライバシー: 開発するコードや扱う情報によっては、Devinの利用におけるセキュリティやプライバシーに関する考慮が必要となる場合があります。
    • チームでの利用: チームでDevinを利用する場合は、役割分担やコミュニケーションルールを明確にすることで、よりスムーズな連携が可能になります。
    • 過度な期待の排除: Devinは強力なツールですが、万能ではありません。Devinの能力を理解し、過度な期待を持つのではなく、人間のエンジニアとの協調を前提として活用することが重要です。
  • b
    • Devinへの過信: Devinを過信し、生成されたコードや提案を十分に検証せずにそのまま採用することは、バグやセキュリティ上の脆弱性を埋め込むリスクを高めるため避けるべきです。
    • 費用対効果を考慮しない利用: Devinの利用料金に見合わない、単純なタスクばかりを依頼することは、コストパフォーマンスが悪くなるため避けるべきです。
    • セキュリティ対策の怠り: Devinの利用環境におけるセキュリティ対策を怠ることは、情報漏洩のリスクを高める可能性があります。
    • チーム内での情報共有不足: チームでDevinを利用する際に、得られた知見やノウハウを共有しないことは、チーム全体の生産性向上を妨げる可能性があります。
    • Devinの進化を無視する: Devinは常に進化しているため、過去の経験や知識に固執し、新しい機能や使い方を試さないことは、ツールの恩恵を最大限に受けられない原因となります。
    • チーム内でのルール不徹底: チームで利用する際、開発ルールや命名規則などを明文化しないと、Devinが一貫性のないアウトプットを生成する可能性があります
    • コスト管理を怠る: Devinは従量課金制であるため、無駄なタスクや非効率的な使用方法はコスト増加につながります。
    • セキュリティリスクへの無配慮: Devinに機密情報を渡すなど、セキュリティリスクへの配慮を欠いた運用は避けるべきです。 これらのポイントを踏まえ、Devinを適切に活用することで、開発効率の向上や人的リソースの有効活用に繋げることができるでしょう。