以前はコードを書く人だけがこの手の自動ループを組んでいた

今年6月頃から、コードを書く人たちの間である手法が広まりました。自走するループを組んで、そのループがAIを動かす——人が一問一答でAIに指示を出す必要がなくなる、というものです。この手法には loop engineering という名前が付いています。Addy Osmani は6月の長文記事の中で、1つのループを5つの要素、それに記憶を加えた構成に分解しています。

この6つの要素はすべてコーディングツールの中で育ってきたもので、使う人もほぼ開発者に限られていました。Loops はこの対象を切り替え、プロダクトチームが日々こなしている定型的な運用作業を受け皿にしています。

右側に挙げた3つの作業は、プロセス自体は明確です。詰まっているのは、誰かが入ってくる変化を見張り、判断を1回下してから動く、という部分です。では Loops はこの手の作業をどうやって引き受けるのでしょうか。まずは実際の姿を見てみましょう。

1つの loop は何で構成されているのか

loop を作るのに必要なのは2ステップだけです。やりたいことを平易な言葉で書き、それを決まった時刻に実行するかイベントで起動するかを選ぶ。中身を見ると、1つの loop には4つの要素がぶら下がっています。

Product standup prep という名前の loop で、Product チームに紐づいています。トリガー方式にはスケジュールが選ばれており、2026年7月15日を起点に2週間ごとの夜9時前後に実行されます。下の Instructions 欄に入っているのが、平易な言葉で書かれた指示文です。出典：Linear 発表ページ

Prepare the agenda for the next Product team standup.

Review the last 2 weeks of product activity and surface the key things the team should talk about live.

Focus on:
- decisions to make
- open questions
- risky assumptions

1回の実行で実際に何が行われるのか

トリガーされるたびに、Linear Agent はその loop の指示を読み直し、今回何をすべきかを自分で判断します。参照できるコンテキストには、Linear 内の issue・プロジェクト・ドキュメント、連携済みのコードベース、接続した MCP ツール、さらにはその loop の過去の実行結果までが含まれます。そのため、例外への対応や、情報が不十分なときにまず確認を取ること、複数の選択肢から1つを選ぶことができます。

公式ドキュメントには、かなり詳しく見られる実例が載っています。RideShare という名前のワークスペースにある、Bug investigation という loop です。まずはその指示内容を見てみましょう。

When an issue enters Triage, run only if it either has the Bug label or uses the bug report template.

Review the issue description, labels, comments, attachments, linked issues, related customer requests, and recent relevant issues across the workspace.

First, determine whether there is enough information to continue triage. The minimum needed is:
- expected behavior
- actual behavior
- reproduction steps
- device and OS information

If materially important information is missing, leave a short comment asking the user for the missing information.

If enough information is present, assess:
- severity as critical, high, medium, or low, with a short justification
- regression risk as likely, possible, or unclear
- duplicate risk as likely, possible, or none found
- the most likely team
- the most likely owner

この指示文はもう少し丁寧に見る価値があります。loop の指示を書くうえでの3つのテクニックを示しているからです。1つ目は前段の絞り込み——冒頭の「Bug ラベルが付いているか bug テンプレートを使っている場合にのみ実行」という一文が、対象外の issue をあらかじめ弾いています。2つ目は出力を限られた選択肢に固定すること——深刻度は critical・high・medium・low からしか選べず、リグレッションリスクも likely・possible・unclear からしか選べません。自由に判断させる余地を与えないことで、結果をそのまま後続の処理に使えるようにしています。3つ目は情報が足りないときに当て推量を許さないこと——まず最低限必要な4つの項目を明示し、欠けていればコメント欄で本人に尋ねる。想像で深刻度を埋めさせたりはしません。

実際に1回実行した結果も見てみましょう。7月9日の夜11時4分の実行では、3分間動きました。RIDE-10663 という issue（機内モードから復帰後に走行履歴が読み込まれない）に振り分けのまとめコメントを投稿し、RIDE-10639 に関連付け、評価結果に沿ってチーム・担当者・優先度・工数見積もりを変更しました。この2つの issue はタイトルが一字一句同じで、重複の疑いがあるものでした。さらに一歩踏み込み、既存の修正を使ってレポートに書かれていた iPhone 17 + iOS 27 での再接続経路を検証し、修正に問題はなさそうでコード変更は不要、マージ前にビルドを1回と実機での機内モード再現が1回必要、という結論を出しています。

Bug investigation という loop の実行履歴。左の列が各実行の時刻で、上部にある Show successful runs というトグルで、成功した実行も一覧に含めるかどうかを切り替えられます。右側の上半分がその指示内容、下半分がその回で実際に行われた内容で、末尾には対応する修正ブランチが表示されています。出典：Linear 公式ドキュメント

この画面には見落としがちな細部もあります。この loop はイベントで起動するタイプなので、実行頻度がかなり高いのです。7月9日1日だけでも、画面上で確認できる実行は16回あり、午後5時49分から夜11時12分まで並んでいます。実行のたびに個別の記録が残るので、後から何を読んで何をしたのかを1件ずつ遡って確認できます。この頻度については後でもう一度触れます。Loops は実行回数に応じて課金されるからです。

どこまでアクセスを許可できるか

これは誰も見張っていない状態で、会社のワークスペース内を動く Agent です。だからこそ、権限のトグルスイッチが決めるのは2つのことです——どこまでのデータに触れられるか、そして中の内容を外部に送信できるかどうか。loop を作るときは項目ごとに検討し、使わないものはオンにしないことです。

新規 loop 作成の最終ステップにある権限パネル。画面には6項目が並んでいますが、上で挙げた7つ目の「トリガーとなった issue 以外への変更」はこのパネルには含まれておらず、ドキュメント本文にのみ記載されています。また、この画面では2つ目の項目のスイッチ名が Web search と表記されていますが、公式ドキュメント本文では同じ項目を Web access と呼んでいます。画面上では、外部同期スレッドと外部ソースからのトリガーの2項目はオフになっています。出典：Linear 公式ドキュメント

ツールはもう1つの経路ですが、権限スイッチよりも境界が狭くなっています。loop にツールを1つ接続することは、そのサービス内で実際に操作する権限をその loop に与えることを意味します。どこまで操作できるかは、2つの範囲の重なりで決まります——その連携自体がどこまでできるように設定されているか、そしてその loop のデータ範囲がどれだけ広いか、の両方です。さらに、各ツールはワークスペース側であらかじめ承認されていないと使えません。ワークスペースの管理者がセキュリティ設定で許可リストを定めます。

この loop には Datadog、GitHub、Intercom の3つのツールが接続されています。下のグレーのバーにある注意書きにはこうあります——個人の認証情報で MCP サーバーに接続することは、その loop にあなたの個人データへのアクセスを許すことと同じである。出典：Linear 公式ドキュメント

チームは今、これで何をしているのか

前節の bug 調査 loop がすでに1つ目の事例なので、ここでは繰り返しません。それ以外に、発表ページと公式ドキュメントではいくつかの用途が紹介されています。うち印の付いた4つはドキュメントページ上でそのまま使えるようになっており、「Build this loop」をクリックすればそのまま作成できます。

When an issue enters this team's triage queue, investigate its likely root cause with Code Intelligence. If you think you can fix it, start a coding session.

Every Monday afternoon, review projects that had their first update in the last week or were mentioned as newly kicked off in @Weekly sync document. Send a Slack message to the #product-marketing channel so they're aware of what's coming.

When an issue is created in team Mobile, create separate issues for the iOS and Android teams, if relevant.

Loops を1回実行するといくらかかるのか

Loops は Business プランと Enterprise プランで利用できます。7月20日以降、1回実行するたびにワークスペースの AI credits が消費されます。この残高はプランに含まれているものではなく、管理者が別途チャージする必要があります。また、すべての AI 機能がこの残高を使うわけではなく、コーディングセッションと Loops だけがこのプールを消費し、それ以外の AI 機能はプラン料金の範囲内です。課金は実際の使用量に応じたもので、席数ベースではありません。

この料金表を前節の数字と合わせて見ると、イベント駆動の loop が実際にいくらかかるのかが分かります。あの bug 調査 loop は7月9日の1日だけで16回起動されており、コーディングセッションを伴わない前提なら1日あたり1.1〜3.2ドルです。しかしその指示文には「解決策が明確であればそのままコーディングセッションを起動して修正する」とはっきり書かれているため、一度でも実際に手を動かせば、その1回だけで3〜5ドルかかります。これは、あの指示文の冒頭に「Bug ラベルが付いているか bug テンプレートを使っている issue にのみ実行する」と書かれている理由の説明にもなっています。前段での絞り込みは、結果の精度のためでもあり、無駄な出費を抑えるためでもあるのです。

お金に関わる点はほかにもいくつかあります。AI credits の利用は任意で、ワークスペースが一度もチャージしなければ Loops もコーディングセッションも使えませんが、その分課金されることも永久にありません。残高がゼロになるか、プロモーション枠の期限が切れると loop は一時停止します。管理者が自動補充を有効にしているか、別途枠を購入していない限りは。自動的に引き落とされるのは、自動補充を有効にしたワークスペースだけです。チャージは Stripe 経由で行われ、Linear のサブスクリプション請求とは別建てで発行されます。どの機能・誰にどれだけ使われたかは、設定の請求ページでリアルタイムの明細を確認できます。

loop を作るには2つの方法がある

1つ目の方法は、まずチャットで試してから、満足のいく結果になったら loop として確定させるやり方です。⌘/Ctrl + J で Linear Agent のチャットを開き、欲しい結果になるまで調整します。満足できなければ要求を出し続け、フォーマットも内容も納得のいくものになったら、Linear にその内容を loop に変換してもらいます。足りないフィールドがあれば、その場で入力を促されます。ドキュメントには、毎週木曜にプロジェクトの check-in ミーティングを開く担当者を想定した、そのまま使える書き出し例が載っています。

Check the project Slack channel, open questions in the last update, and any issue threads that seem relevant. Add a new section in the Meetings project document with those details, using a format like [...]

2つ目の方法は、画面上で直接作成するやり方です。サイドバーのワークスペースのグループで Loops をクリックすればワークスペースレベルの loop を作成でき、チーム名をクリックしてから Loops タブを選べばそのチーム用の loop を作成できます。あとはトリガーを選び、指示を書き、必要であればツールを接続し、範囲と権限を一通り確認します。

誰が loop を作成・管理できるかも制御可能です。ワークスペースレベルの loop はワークスペースのオーナーがセキュリティ設定で管理し、チームレベルの loop はチームのオーナーがチームのアクセスと権限設定で管理します。

今後 Linear は、さらに多くのトリガー方式やコンテキストソース、そしてワークスペース・チーム管理者向けのガバナンス制御を追加していく予定です。

Linear は7月20日、Loops を公開しました。繰り返しやらせたいことを平易な言葉で書き、決まった時刻に実行するか issue の変更で起動するかを選べば、あとはワークスペース全体でずっと動き続けます。かつては人が張り付いて下していたあの判断が、今では一文の指示として書けるようになったのです。

同じ書き方は他のことにも使えます。新しい要求が来たら iOS・Android・Web 3方向のサブタスクを自動で派生させる。毎日の終わりにプロジェクトとリリース計画のドキュメントを照合し、変化があれば修正して理由をコメントで残す。インシデントがクローズされたら根本原因分析を行い、フォローアップすべき事項を新しいタスクとして作成する。ただ、ここで疑問も湧いてきます。この一文の指示は、起動されるたびにどうやって実際の動作に変わるのでしょうか。

1つの loop には4つの要素がぶら下がっています——トリガー（決まった時刻、または issue が条件に合致したとき）、平易な言葉で書かれた指示、任意で接続する外部ツール、そして一連の権限スイッチです。決まった手順をなぞるスクリプトとは違い、起動されるたびに書いた指示を読み直し、そのときの材料を見て、何をすべきかを自分で判断します。下の図は、公式ドキュメントに載っている実際の bug の流れをたどったものです。Linear のドキュメントで紹介されている、RideShare という名前のワークスペースの例です。

Loops は席数ではなく、起動された回数に応じて課金されます。コストの大小を左右する要素はほぼ1つ——コードを実際に変更させたかどうかです。ドキュメントに載っているあの調査 loop は、7月9日に16回起動されており、2つの運用パターンで1日あたりのコストが桁違いに変わってきます。

利用条件：Business または Enterprise ワークスペースが必要です。この残高はプラン料金には含まれておらず、管理者が能動的にチャージする必要があり、手動チャージは1回最低10ドル、残高がゼロになると loop は一時停止します。以上の価格と枠はすべて Linear 公式の課金ドキュメントによるもので、第三者による裏付けは取れていません。