1. はじめに

こんにちは！

今週はDXソリューション事業本部 Devグループマネージャーの小倉が担当します。

燈ではDevinを中心とするAIを用いた開発ツールを積極的に導入しています。

今回はAI（Devin）を使って開発した際の所感と、タスクの切り分けに関するグッドプラクティスをご紹介します！

2022年にChatGPTやCopilotが登場して以来、研究者以外の方々にもAIが身近になってきました。

近年ではLLMがさらに発展し、Agentのように意思決定を伴うタスクをAIに自律的に実行させることで、より複雑なタスクもこなせるようになっています。

本記事では、現在のAI開発における所感やグッドプラクティスを共有しつつ、「人間もまだまだ成長が必要だ！」というメッセージをお伝えできればと思います。

2. Devin について

Devin（デビン）とは

Devinは、AIスタートアップ企業Cognitionが開発した完全自律型のAIソフトウェアエンジニアで、ソフトウェア開発の全工程（要件定義、設計、コーディング、テスト、デプロイ）を人間の指示なしに実行できる革新的なツールです。

devin.ai

Devinの特徴

Devinは、開発者の負担を軽減し、より創造的な業務に集中できる環境を提供することを目的としており、以下の特徴があります。

完全自律型: 従来のAIツールのようにコード生成やバグ修正といった一部のタスクをサポートするだけでなく、開発プロセス全体を自律的に実行できます。
高い汎用性: 主要なプログラミング言語やフレームワークの知識を持ち、多様なソフトウェア開発プロジェクトに対応可能です。
エラー修正能力: 開発中に発生したエラーをリアルタイムで検出し、自律的に修正できます。
進捗報告: 開発の進捗状況をリアルタイムで報告し、開発チームとの円滑な連携を促します。

さらに、Slack上で指示を記載したIssueを連携するだけで、方針の共有からプルリクエスト（PR）の作成まで、一連のタスクを自律的に実行します。

slackでタスクを振り、Devinが起動するイメージ

所感

一通りDevinを使ってみて、「エンジニアの代替にはならない。しかし、使い方次第で生産性を飛躍的に向上させられるツールである」と感じました。

実装は難易度によらず一定の時間を必要とします。また、エンジニアのレベルが上がったとしても、基本的には1つずつのタスクをこなすことしかできません。

しかし、Devinを使えば複数のタスクを並列に進められるようになります。自身のエンジニアリング力を向上させ、一度に任せられるタスクの数を倍増させていくことができれば、その能力に応じて非線形に生産性を向上させていくことができるでしょう。

なぜ、エンジニアの代替にはならないか。

現状のDevinは、人間の意図を汲み取る力がまだ弱いからだと考えます。

例えば、プロジェクトの背景情報や文脈を事前にインプットできれば、ある程度は意図を汲み取れるかもしれません。しかし、こちらが意図していることの全てを言語化するのは困難です。また、LLMが一度に処理できる情報量（コンテキスト長）にも限りがあるため、完全には意図を汲み取れないのが現状です。

では、どうすれば生産性を上げられるか

AIが人間の意図をあまり汲み取ってくれない中で、どのように生産量上げていくべきか考えた時、以下の2つが重要だと考えます。

マネジメント力を向上させる
1. 並列にタスクを依頼する。
2. 適切な粒度でタスクをふる依頼し、曖昧なタスクは振らない依頼しない。
3. 実現が困難そうなタスクは依頼せず、自ら巻き取る。

これらはマネジメントの基本ですが、多くの方は改めて意識する必要があるでしょう。

（特に、優秀なメンバーは意図を汲んで柔軟に対応してくれるため、「自分はタスクをうまく切れている」と錯覚しがちです。Devinは、タスクの粒度でアウトプットの質が顕著に変わるため、適切な粒度でタスクを分解できているか、改めて吟味する必要があります。）

エンジニアリング力を向上させる。
1. レビュー力
  - 意図していないコードが生成されることもあるため、それらを漏れなく検出し、的確にレビューする能力が重要です。
2. 実装のプランニング力
  - つい手を動かしながら考えがちですが、実装に着手する前に全体の計画を立てる能力が重要になります。

タスク切りのグッド/バッドプラクティス

改めて、タスク切りにおいては、曖昧さをなくし、論点を明確にすることが重要です。

バッドプラクティス

論点を2つ与えてみた際の例

PRのリンクを2つ同時にDevinに投げたところ、Devinが方針を検討してくれます。

## Task description
Fix frontend CI failures for PR 314 and PR 315 in the {repository name} repository. PR 314 is already passing all checks, but PR 315 has TypeScript compilation errors that need to be resolved.

## Procedure

1. **Verify PR 314 status** - PR 314 is already passing all CI checks (frontend, backend, AWS Amplify), so no action needed.

2. **Fix missing import in SimilarMaterialsDrawer** - Add the missing import for `useFetchMaterialUnits` in `SimilarMaterialsDrawer.tsx`:

結果を見てみると、「CIは通ってるのでアクションは起こす必要がない」とDevinが判断してることがわかります。

もし「CIを通してください」というタスクを依頼された場合、経験のあるエンジニアであれば、以下のような思考プロセスを辿るでしょう。

まずGitHubで状況を確認する。
GitHub Actionsが失敗している原因を特定する。
原因を解決するための具体的なアクション（例：コードフォーマッターの実行など）を取る。

しかし、Devinにこのように複数の「論点」（この場合はプルリクエスト）を一度に与えると、処理のコンテキストを混同するためか、実際にはCIが失敗しているにもかかわらず、「すでにCIは通っています」といった意図しない応答をすることがあります。

タスクが曖昧な例

以下の内容で指示をしました。

{path}/index.tsxでConstructionsListに関してページネーションを実装したいです。

するとページネーションとは全く関係のないCSSの調整のみを行う、意図しないプルリクエスト（PR）が作成されました。

以下のタスクに分解することで解決！

既存のAPIにページネーション機能を追加。
上記APIのエンドポイントを伝えた上で、再度同様の指示を出す。

※個人的には、上記の分解粒度もまだ粗いと感じましたが、ページネーションはAIにとっても一般的な概念なため、試しにこの粒度で依頼したところ、求めている内容を実装しました。

グッドプラクティス

基本的には、以下の点を明確に伝えることが重要です。

対象: どのコードを変更するのか
目標: どのような挙動を期待するのか
方法: どのように変更するべきか
(現状: 現状、どこに問題があるのか)

また、LLMは過去のやりとりを忘れがちなため、コンテキスト長を意識し、なるべく少ないやりとりでタスクを完了させることも重要です。

ラフなプロンプト例

下記はラフなプロンプトの例ですが、これらの要点を押さえておけば、2往復程度のやりとりでマージ可能なレベルまで持っていくことができます！

```bash
pdf統合のhooksを統合したいです。
{path}/frontend/src/hooks/usePdf.tsxと
{path}/frontend/src/hooks/usePdfManager.tsxを統合して。
また、managerの中にあるgetPdfContentで実際のAPIを叩くようにして
```

```bash
工事一覧ページは{path}/frontend/src/pages/index.tsxにあります。
工事詳細ページは{path}/frontend/src/pages/detail/[constructionId]/index.tsxにあります。
工事詳細ページにflexやbox、fixedなcomponentなど追加、編集を行い工事一覧UIに寄せたいです。
現状は工事詳細ページがsearchPanelに一覧結果が重なって表示されています。
```

```bash
{path}/frontend/src/components/constructionsList/PdfModalTriggerButton.tsx
にあるpdfの情報をhooksに切り出してください。
hooksにはpdfの登録関数や、reset、pdfの中身の情報を処理するためのapiにfetchする関数などを定義してください。
pdfを表示するモーダルにはリセットボタンも配置し、再度pdfをアップロードできるようにしてください。
モーダルに表示する工事名は、 「pdfの中身の情報を処理するためのapiにfetchする関数」の出力である工事名を表示してください。
ここで、fetchする関数の中身自体はdummyを返すだけでいいです。
```

3. 最後に

個人的には、まだAIはエンジニアの代替になるレベルではないと思います。

しかし、私たち自身のエンジニアリング力やマネジメント力を向上させることで、その生産性を飛躍的に高められるポテンシャルを秘めています。そのためにも、まずはAIを使う私たちユーザー自身が、より高い意識を持って成長していくことが重要です。

この可能性には、非常にワクワクさせられます。

また、AIが理解しやすいドキュメントやリポジトリを整備していくことも重要だと考えます。 AIがこちらの意図をいかに汲み取るかは、どれだけ多くのコンテキストを共有できるかにかかっています。リポジトリの構成やドキュメントの書き方、配置などを工夫することで、AIとの連携を深め、さらなる生産性の向上を実現できるでしょう。

ledge.ai