はじめに
みなさんこんにちは。
前回、弊社でもDevinが投入され始めていることを記事にさせていただきました。Devinの得意なことや苦手なことを紹介し、実践したことも簡単にまとめています。まだご覧になられていない方は、ぜひご覧ください！
Devinの苦手なこと
さて、前回の記事ではDevinの苦手なこともまとめました。この記事でも、改めて苦手領域について確認します。chat GPTが次のようにまとめてくれました。
- 🧠 「全体的な抽象理解・意味構造の把握」
- 🧭 ユーザーの意図を曖昧なまま処理すること
- 🧩 ドメイン知識が必要な特殊分野
- 🧪 ユーザーとのインタラクティブな仕様調整
- 🕳️ バグ検出やデバッグの深堀り
- 🎨 「創造性」や「美的判断」が必要な領域
意外と苦手なことがあるんです。でも、これらは苦手なので、前回の色を変えるタスクをお願いしたように、完璧にできないということはありません。
では逆に、どこまではできるのでしょうか？ この苦手を検証するために、次の３つの視点に分けると分けてみます。（これもchatGPTにおねがいしました笑）
- Devinを迷わせる（仕様不明瞭・曖昧）
- Devinに限界を超えた範囲を与える（コード規模、専門性）
- 人間的な判断や創造を求めるタスクをあえて投げる
今回は、この３つのタスクについてテーマを考え、実際にDevinを動かしてどの程度頑張ってくれるのか、検証をしてみようと思います。
Devinの苦手なことをやらせてみる
1.Devinを迷わせる
さて、最初はDevinを迷わせます。検証では、「仕様なしで社内向け日報投稿ツールを作らせてみる」というテーマでDevinを動かしていきます。曖昧な指示で、使用不明瞭の中、どこまで自立してツールを作れるのでしょうか。不足情報を勝手に補完して暴走するのか、仕様の聞き返しが発生するのか、これらが注目ポイントになってきます。それでは早速指示を出してみましょう。
まずは、指示を出します。「日報をSlackに投稿するツールを作ってください」と指示を出しました。
この曖昧な指示に対して、Devinは自ら調査してシンプルなwebアプリケーションを開発してくれるようです。特に仕様を聞き返すことなく作業を始めました。
しばらくすると、特に何事もなくコーディングを始めました。すると、ツールの開発が完了したのか、アプリケーションをインターネットへ公開してURLで渡してもいいかと聞かれました。そのため、デプロイの許可を求めてきました。
デプロイ先は、devinapps.comという場所で、ここは後から調べたら分かったのですが、Devinが開発中のアプリケーションなどが一時的に確認できるおよう準備されているサーバーのようです。
ですが、開発中の私はよくわからなかったので、とりあえずGitHubにPR作成するよう指示を出して終わらせることにしました。
さて、では実際にどのようなものが出来上がったのか、みてみましょう。
青ベースのシンプルなフォームが出来上がっています。最初にDevinが言ったように、確かにシンプルですね。React+TS構成で、下にはプレビュー機能もあります。なかなかいい出来ですね。
さて、今回のこの出来栄えはどうなのでしょうか。苦手分野を３つやらせるということで、公平なジャッジをするためにもchatGPTに聞いてみましょう。すると、次のようにジャッチしてくれました。
| 評価軸 | 判定 | コメント |
|---|---|---|
| 技術選定・構築力 | ★★★★★ | ✅ React+TS構成と技術スタックは文句なし |
| UX・実装品質 | ★★★★☆ | ✅ プレビューやレイアウトも丁寧 |
| 自律性・仕様推測 | ★★★☆☆ | △ 「課題欄」の追加など積極推測は好評価だが、確認はせず |
| 発展性・想像力 | ★★☆☆☆ | △ 履歴や管理機能がなく、テンプレ的 |
| デプロイ提案 | ★★★☆☆ | ⚠️ devinapps.comの提案は意欲的だが実体不明 |
総合評価：8/10
– 「曖昧な仕様でも即戦力となる日報アプリを構築」できた点は大きく評価できます。ただし、確認プロセスや発展的な発想には乏しいですね。これは「聞き返さないAI」の典型的傾向とも言えます。
最低限の機能は盛り込み、UI/UXも意識しているいい評価があった一方、仕様の聞き返しや謎のデプロイ環境への不安など、辛口なコメントもありました。ちなみに、ここまでで消費されたACUは1.36でした。みなさんはどのように感じましたか？
作ってくれたコードは、GitHubにも上がっていますので、曖昧な指示からの成果物として参考にしてみてください。
2. Devinに限界を超えた範囲を与える
次は、Devinの記憶力を試していきます。検証では、「複数ファイル構成のMVCアプリを読み取らせて、全体仕様を文書化させる」という内容をやらせます。10個のファイルを与えて、複数の項目を記憶しながら、ファイルごとの関係性を構築し、人間が分かるような仕様書になっているかを試していきます。
指示では、最初に「これから１つずつファイルを渡すから、構造を理解して仕様書をまとめてね」と言いました。その後、10個のコードを投げていきます。コードはchatGPTに作成してもらい、それを一つ一つコピペしてDevinへ教えていきました。
それでは早速始めていきます。
すると開始早々、すでに連携しているリポジトリのコードを読み始め、仕様書を作ろうとしていました。でも、気にせずコードを送り続けます。
すると、2つ目あたりのコードから、やっと理解をしてくれました。その後もどんどんコードを送っていきます。そして最後に、全てのファイルを送ったことを伝え、仕様書を作るよう指示をしました。
その結果、3つのマークダウン形式のファイルを作ってくれました。でも、うち２つは作りかけで、しっかりとできていたのは３つ目だけでしたが（笑）。消費されたACUは0.75でした。
しかし、結果は素晴らしいもので、１回目の検証と同様、chatGPTにジャッチしてもらったところ、なかなかの高評価でした。
| 評価軸 | 評価 | コメント |
|---|---|---|
| 構造理解 | ★★★★★ | 完璧に近い。レイヤー分離と各責任が明示されている |
| 記憶・関係性保持 | ★★★★★ | 全10ファイルの意味と接続関係を保持しており、記憶破綻なし |
| 文章構成・可読性 | ★★★★☆ | 一部やや情報密度が高いが、仕様書として実用レベル |
| API記述精度 | ★★★★★ | 期待された4つのエンドポイントを正確に網羅。レスポンス例まで記載 |
| 創造的補完力 | ★★★★☆ | 「今後の拡張案」など、オリジナルには無い要素も記載（やや保守的だが◎） |
| 弱点 | ★★☆☆☆ | UIやUXに関する配慮は皆無だが、これは本件の目的外なのでOK |
総合評価：9.5 / 10 – 完全勝利に近いパフォーマンス
– Devinは、断片的な情報（10ファイル）を統合し、意味のあるドキュメントに昇華できることを証明しました。各要素（構造／機能／API仕様／セキュリティ）のつながりも理解しており、文書としての整合性・実用性ともに非常に高いです。
かなりの高評価でした。記憶に関しては、ファイルを1から10までしっかり受け取れているメッセージが出ていたので、問題はなさそうでした。これがもう少し数が多くなった時にどうなるかは、見ものですね。Devinが作った仕様書もGitHubに共有してありますので、よければご覧ください。
3. 人間的な判断や創造を求めるタスクをあえて投げる
最後の検証では、Devinのデザインセンスについて測っていきます。ここでは、「おしゃれなプロフィールサイトを作らせる」ということをやらせます。Devin自身の判断力で行うため、最初の指示でも、何を問いかけられても、自分で考えるよう指示をします。
それでは早速指示を出していきましょう。
すると、リポジトリーの指示など特に出していなかったため、さきほど作ったSlack日報ツールを書き換えて作り始めてしまいました・・・。この時点で技術ベースは先ほどと一緒の構成です。
色合いや内容に関しては、やはり指示をもらいたいようで、「どのような情報を含めたいか（自己紹介、スキル、経歴、ポートフォリオなど）とデザインの好み（色合い、レイアウトスタイル）を教えてください。」など、詳細な意見をもらおうとしてきました。これはテーマ1,2ではみられなかった反応ですね。
ここがDevinの限界ということでしょうか。しかし、ここでデザインに関して口出しをしてしまうと、Devinの自立的にできる限界が図れないので「Devinの判断でいいですよ！」と辛口な反応をします。
その後、しばらくして作成が完了したと報告がありました。
消費されたACUは1.05、仕上がりは以下のとおりです。可もなく不可もなく・・・。普通ですね。
さて、毎度お馴染みchatGPTジャッチはどうでしょうか。
| 評価軸 | 評価 | コメント |
|---|---|---|
| UIセンス | ★★★☆☆ | 配色と構成は破綻なし。でも光らない |
| UX設計 | ★★★☆☆ | 見やすいが、体験的ではない |
| 構成力 | ★★★★☆ | セクションの順番・整いは良好 |
| 創造性 | ★★☆☆☆ | テンプレ脱却なし。AIの限界が見えた |
| 技術選定・実装力 | ★★★★☆ | 問題なし。むしろ堅実で丁寧 |
総合評価：6 / 10
– 最低限の“まとまり”は出せている。でも、オシャレとは「言いづらい」し、意外性や表現力には欠ける。デザインセンスや創造性が問われる領域では、最も“安全な選択肢”に着地する傾向が強く、「ちょっと面白みがない」レベルにとどまる。
なかなかの辛口評価。でも、デザインを学んでいた私も同じように感じました。
やはり、創造性という部分では、Devinのドキュメントにもあるように、苦手としている分野だなと感じました。よく見るサイトって感じですね。
Slack日報ツールの時もそうですが、基本的なUIは備えるものの、それ以上の他にはないような驚きや斬新さを感じられるものは、Devinには苦手なようです。逆に言えば、基本的なデザインにして！と言えば、ある程度のところまでは作ってくれることがわかりました。
GitHubにコードが追加されていますので、よければご覧ください！
Devinの苦手分野をやらせてみて、見えたこと。
さて、ここまで「曖昧な指示に対しての自立力」「断片的な情報の統合力」「感性やセンスが必要な想像力」をみてきました。今回の検証を通して、次のことが見えてきた気がします。
構造的に整理された世界には強い
検証２でも示したように、MVCアーキテクチャのように、関係性が明確な環境では、的確に全体像を捉えて再構築することができました。これは、今回は10個のファイルでやりましたが、おそらく関係性が明確であれば、ファイル数を増やしても問題なく全体像を捉えると思います。
Devin wikiのような全体像を把握するツールがあるわけですから、このような作業は得意なのかもしれません。整理された複雑さは、Devinの得意領域と言えるでしょう。
Devinは人間のような気配りには届かない
検証１や検証３でやったような、詳細が不明瞭な指示に対しては、Devinは基本的な機能を兼ね備えたものしか作れませんでした。詳細な仕様を聞き返すこともなく（場合によっては聞き返すかもしれませんが）、とりあえず動作する、基本的なものを目指して作っていきます。
Devinの公式ドキュメントにもありますが、ACUの消費を減らすためには、指示を出す際に曖昧な指示ではなく、何をどのように作りたいのか、詳細に教えてあげる必要がありました。エンジニアがどのような開発をすればいいのかイメージを持って指示を出してあげることが大切です。
Devinの創造力は平均値
検証３のように、Devinにデザインに関する創造性を任せると、テンプレートレベルを作ってくれます。つまり、それ以上の飛び抜けた提案はできないので、UI/UXを含めたデザイン性を高めるためには、デザイナーの力が必要だと思いました。逆に、テンプレートレベルでいい（UI/UXを含めたデザイン性にこだわらない）のであれば、考えることは少なくスムーズに設計に入れそうです。
これも公式ドキュメント通りにはなりますが、Devinの創造性は平均点であって、飛び抜けた提案力はありません。使いやすいサービスや、また使いたくなるようなユーザー体験を提供するためには、デザイナーの力は必須です。
おわりに
さて、今回はDevinの苦手とすることを３つの検証を通してやらせてみました。
その結果、整理された複雑さは得意とするものの、基本設計を超えたオプション的な要素であったり、ユーザーの体験を向上させるようなサービス全体のデザイン（設計）や、使いやすさを求めたUIデザインは、Devinに指示を出す人が十分に出してあげなければいけないことがわかりました。
今回は検証としてやっていませんが、複雑なエンジニアタスクはまだ苦手そうですので、デザイナーがプロダクト全体の設計やUIを考え、基本的なコーディングをDevinがし、複雑で応用的なタスクや最終的なコードレビューはエンジニアがするという三角関係が、今の開発の現場では最強のチームかもしれません。ぜひ皆さんもDevinを使ったコーディング、やってみてください！
AIをフル活用できることに越したことはありませんが、まだまだ開発現場では人間の力が欠かせませんね！
ここまでご覧いただき、ありがとうございました！