タイミーの技術ブログ

全321件

2026/11/09

こんにちは、タイミーで開発生産性改善チームのマネージャーをしている新谷です。みなさん Devin を使っていますか？タイミーでは日々 Devin が仕事をしてくれています。 Devinは単にタスクを依頼するツールにとどまらず、ソフトウェアファクトリーのフレームワークになりました。最近の進化が著しいので紹介させてください。本当にすごい。ソフトウェアファクトリーとは LayerX CTOの松本さんが、 Xの投稿で次のように述べていました。ソフトウェア開発は、人間がCoding Agentをどう使うかを考える段階を過ぎた。これからは開発プロセスそのものを、ループが閉じたプロダクトとして作る段階で、そこまでやって初めてファクトリーと言える、という主張です。添付されていたスライドには、ループが3つ描かれています。 Inner Loop: 計画→実行→検証→補正を回して、1つのタスクを完了させる Outer Loop: 検証の結果から学習し、知識・記憶として次の計画に活かす Harness Optimization Loop: 人間の評価を、エージェントを動かすハーネスやプラットフォームの改善につなげるこの記事では、3つのループが人の手を離れて回っている開発の仕組みをソフトウェアファクトリーと呼びます。以下は、その内容をもとに、自分なりに整理した図です。成熟レベルはループがどこまで閉じているかで決まる 3つのループがどこまで閉じているかを、自分なりに段階に分けて整理してみました。レベル段階状態 Lv.0 人がエージェントを使う手元のエージェントに書かせて、人が見て直す Lv.1 Inner Loopが閉じているタスクを渡すと、エージェントが自分で動かして確かめ、直したうえでレビューできるPRを出してくる Lv.2 Eventで起動する人がプロンプトを打たなくても、バグ報告・Issue・アラート・問い合わせをきっかけにエージェントが動き出す Lv.3 Outer Loopが閉じている失敗やレビューでの指摘が知識になり、同じ指摘の繰り返しを減らせる Lv.4 Harness Optimization Loopが閉じているマージした、差し戻した、手で直した、といった人の評価を集計して、ハーネスそのものを改善するループが閉じるほど、遅さの原因は人間側の承認フローに移っていきます。この成熟レベルを上げるには、人間がトリガーしなくても仕事が始まり、人間が全部を見なくても承認できることが必要です。ループを増やすにはプラットフォームが必要こうした仕組みは個別の部品を作るだけなら、GitHub Actionsなどの既存のツールでも実現できます。たとえば、イベントをきっかけにエージェントを動かし、結果を通知する、といった小さな自動化です。ただ、小さなループをその都度作って積み重ねていくと、設定や実行状況を管理するのがだんだん大変になり、いずれ手に負えなくなる可能性が極めて高いと考えています。本気でソフトウェアファクトリーを作るなら、トリガーとなるイベント、エージェントの行動、終了時や失敗時の通知などを共通の方法で設定・管理できる、一般化したプラットフォームが必要です。 *1 Devinはソフトウェアファクトリーのフレームワークこの面倒なところを肩代わりしてくれるのが、いまのDevinです。最高。 Devinの機能を少し前に提示した画像に当てはめると、次のようになります。ここからは、Devinが持つパーツを順に見ていきます。起動：オートメーションで仕事を始める 1つ目の部品はオートメーションです。Lv.2のEventで起動する仕組みを誰でも作れるようにしています。オートメーションは、次のような部品を組み合わせて設定します。詳しくはドキュメントをご覧ください。部品内容トリガー Slackの投稿やリアクション、GitHubのPR・Issue・CIの結果、セキュリティスキャン、決まった時刻、Webhookなどトリガーの条件「labelがbugのときだけ」「このリポジトリだけ」のように、トリガーを絞り込む条件プレフライトチェックイベントが条件に合ったあと、Devinを動かす前に通すフィルタエージェントの定義新しいセッションを始める、動いている既存のセッションにメッセージを送る、Slackチャンネルを見張るトリアージ役として動く通知と上限成功時・失敗時のメール、実行結果のSlack投稿、セッションごとのACUの上限、1時間あたりの実行回数の上限、同時実行数を絞るキュー、ネットワークの制限人間がトリガーしない仕事を回すには、失敗時の通知、暴走したときのコスト上限などのガードレールが必要です。気を利かせてくれていて良いですね。プレフライトチェックは自然言語で書けるフィルタこれもあるのかと感心したのがプレフライトチェックで、LLM filterとスクリプトの2種類から選べます。 LLM filterでは、通過させたいイベントを「認証サービスに関するPR」「新谷へのSlack連絡」のように普通の文章で書きます。すると、decision modelがイベントを1件ずつ読んで、合わないものをスキップします。少し前に話題になったTypeSafeのJevや、OpenAIのDecisions APIのように、文章を生成せずに判定だけを返すモデルを使ったフィルタが、サクッと使えるわけです。スクリプトを選ぶと、スクリプトがセッションとは別の短命なVMで動きます。イベントを読んで、実行するかスキップするかを返すほか、1つのイベントを複数の作業に分けて、作業ごとにセッションを立ち上げることもできます。最初は自動化の提案から始めるとはいえ、部品がそろっていても、何を自動化すればいいかはすぐには思いつきません。スターターキットでいえば組み立て説明書にあたるのが、オートメーションの作成メニューにある Devin におすすめの自動化を提案してもらう機能です。ボタンを押すと「Automations picked for you」というDevinのセッションが起動します。最初のメッセージは自動で入り、一番役に立つ自動化を提案し、その提案をSlackのDMでも送るようDevinに頼む内容です。Devinはユーザー自身のSlack・GitHub・これまでのDevinのセッションを見て、どんな自動化を導入するとよさそうかを、そのセッションの中で提案してくれます。 Devinのセッションは通常課金対象です。ところがこの機能を通じて起動したセッションはこちらからメッセージを送信しない限りは課金されません。Devinに提案してもらう分は無料なので、全人類やるべきだと思います。一方、オートメーションが有効化されれば、その分はDevinの費用として計上されるわけです。提案を無料にするのは、プロダクトとしてよくできているなと感心しました。しかも、自動化の提案には、確かに自分が普段やっているな、と思う作業が出てきます。加えて、PRを作るだけで終わらず、Slack投稿やメール通知までがオートメーションの内容になってます。設定するだけで、その仕事からある程度解放されるわけです。実行・検証・承認：変更を出荷できる状態にする Inner LoopはDevin Reviewが回す 11月に出た Devin Review 2.0 では、8月と比べてPR1件あたりのレビューコストが82%下がりました。 Devinが作ったPRでは、Devin Reviewの指摘をDevinが調べ、指摘ごとに直すか、見送るか、人間に回すかを判断します。人が戻ってきたときには、人の注意が必要な問題や判断に集中できるわけです。ただ、最初のうちはレビューの指摘がいつも正しいとは限りません。Devin Reviewでは、リポジトリの REVIEW.md にレビューの指示を書けます。重点的に確認したい箇所やプロジェクト固有のルールを書いておくと、Devin ReviewがPRの分析時に参照します。ここでオートメーションの出番です。たとえば、週に1回Devin Reviewの指摘を集計し、レビューの指示を直すPRを作るオートメーションを用意すればいいわけです。そうすれば、Devin Reviewのチューニングも半自動で回せます。Devinが指摘を直すところまでがLv.1のInner Loopで、レビューの指示を直し続けるのはLv.3のOuter Loopを閉じる動きです。 Devin Securityもオートメーションに載る 10月に出た脆弱性診断を行ってくれる Devin Security 2.0 も、オートメーションと組み合わせられます。オートメーションからコードスキャンを定期的に走らせたり、新しいコミットが入ったら再スキャンしたりといった使い方です。SnykやWizなど他のツールの指摘を取り込むこともでき、指摘ごとにDevinが修正のPRを作ります。いろいろな脆弱性の情報をきっかけに、修正まで自動で進む状態を作ることができます。承認はAutoapproverで仕分けするもう1つすごいと思ったのが、Devin Reviewの設定にあるAutoapproverです。ルールで対象のPRを選ぶと、Autoapproverが自動で承認するか、人にレビューを回すかを判断します。 AUTOAPPROVE.md には、チームが自動で承認してよいと考えるものや、必ず人の確認が必要なものを記載できます。これを使えば、人間が確認するものとAIが自律的に承認してよいものの線引きを、フレームワークに乗った形で決められます。自動化を増やしていくと、最後は「誰が✅を出すか」が詰まるわけで、そこを自社で一から考えなくていいわけです。学習・改善：実行結果を次に活かす Outer LoopはMemoryとscratchpadが回す Outer LoopはInner Loopの検証から出て、学習を通り、知識・記憶として次の計画に戻ってきます。Devinでこれにあたるのが、10月に発表された Memory and Dreaming と、オートメーションのscratchpadです。 Memoryは、Devinが仕事をしながら学んだことを短いメモとして残し、次のセッションに持ち越す機能です。ユーザーが訂正した前提や、何度か試してようやくうまくいった環境の落とし穴などが残ります。Dreamingは毎日動くバックグラウンドのセッションで、過去の会話とメモを見直して、重なったメモをまとめたり、使われていない古いメモを消したりします。ただ、Memoryは組織で共有されるものではなく、ユーザーごとのものです。そこで真価を発揮するのがscratchpadです。scratchpadはオートメーションの種類ごとに共通で使える長期メモリーです。前の実行で詰まったことをここにメモしておくと、次の実行で同じ問題を避ける手がかりになります。イベント駆動で何度も動くオートメーションにとっては、実行をまたいで学びを持ち越すOuter Loopそのものです。 Harness Optimization Loopもオートメーションで組み立てられる Lv.4のHarness Optimization Loopには、専用の機能があるわけではありません。ただ、Devinの部品を組み合わせれば、既存の機能で半自動までは組み立てられます。たとえば、スケジュール実行のオートメーションを1つ用意します。毎週、イベント駆動のオートメーションが実行したセッションを見直し、精度が微妙なものや、もっと少ないターン数で終わらせられそうなものを探します。そのうえで、ハーネスの改善を提案させます。直す先は、オートメーションの設定かもしれないし、コードベースの中にあるハーネスかもしれません。ただ、提案を採用するかどうかは、今のところ人が判断する部分が大きいと感じています。何を良しとしてハーネスをどう変えるかは、まだ人が介入する余地があります。これからAI活用を進めていく会社ほど効果的このフレームワークは、AI活用がそこまで進んでいない会社にとって特に便利だと考えています。トリガー、通知、レビュー、セキュリティ、承認の線引きまでがひとつながりの機能として用意されているので、仕組みをすべて自前で作る必要がありません。自動化の提案をもらい、気に入ったものを設定するところから始めれば、その会社のAI活用レベルを一気に底上げできるのではないでしょうか。将来、Devinを使い続けずにソフトウェアファクトリーを内製することにしたとしても、まずはDevinを試して、お手本となる仕組みを学ぶのは効果的です。Devinを使い続けるかどうかにかかわらず、一度試してみることをおすすめします。まとめ Devinは、ソフトウェアファクトリーのフレームワークになっています。起動にはオートメーション、Inner LoopにはDevin Reviewと REVIEW.md によるレビュー指示、承認にはAutoapproverとAUTOAPPROVE.md、Outer LoopにはMemoryとscratchpadがそろっています。これらの部品を組み合わせれば、Lv.2〜3に向けて一気に進めるのではないでしょうか。Lv.4のHarness Optimization Loopも、定期的なオートメーションで見直しと提案までは組み立てられ、人は判断に集中できます。 …と、ここまでDevinの機能や組み合わせ方を紹介してきましたが、タイミーでも、これらをすべて活用できているわけではありません。これから活用を広げていきたいと思っています。 *1 : これをやりきっている LayerX は本当にすごい https://speakerdeck.com/layerx/built-our-own-background-agent-at-layerx-number-aidevex-findy

GitHub, セキュリティ, ネットワーク, 大規模言語モデル（LLM）, 開発プロセス

タイミー の技術ブログ

コンテンツ

タイミーの技術ブログ