Loop Engineeringの実践方法：GitLab × Claude Codeでの実装例

編集部注：私たちは時折、パートナーコミュニティのメンバーにGitLabブログへの寄稿をお願いしています。今回、ソニービズネットワークス社のエンジニアである濱田一成氏に、執筆いただきました。過去の寄稿はこちらでご覧いただけます。

ソニービズネットワークスのGitLab Partner Championsの濱田です。

最近、最先端のAIエンジニアの間でLoop Engineeringという概念が流行っています。名付け親であるAddy Osmani氏は、「これが、コーディングエージェントとの協働方法の未来になるかもしれないと考えています。」と述べています。（同時に「しかし、まだ初期段階であり、私は懐疑的です。」とも述べていますが）

Loop Engineeringとは、簡単に表現するなら「AIエージェントに、目的を達成するまで自律的に動いてもらえる仕組みを作る事」です。私自身も、AIコーディングエージェントを使っているうちに人間がボトルネックであると感じてきており、どうにかAIエージェントに自律的に動いてもらえないか最近試行錯誤していました。

そこで、本日はGitLabとClaude Codeを使って、Loop Engineeringを実装する例をご紹介します。

この記事でわかること

• Loop Engineeringとは何か
• GitLabとClaude Codeを使った実装例（cron起動、Skills活用、ラベルベースのフロー）
• AIエージェントを自律稼働させる際に必要なガードレールの設計方法

Loop Engineeringとは

先ほども簡単にお話ししましたが、Loop Engineeringとは「AIエージェントに、目的を達成するまで自律的に動いてもらえる仕組みを作る事」です。

Claude Codeを使った時の一番簡単な例は、以下です。

      #!/bin/bash
claude -p "ログを確認して、エラーがあったら分析して報告して下さい。"

    

このシェルスクリプトをcronで10分毎に実行すれば、立派なLoopの完成です。Claudeが10分毎にログを確認して、何かあったら報告してくれるようになります。

この例のプロンプトは定型ですが、都度、任意のプロンプトを組み込めたら柔軟に動いてもらえそうです。

これを、GitLabで実装します。

GitLabでのLoop Engineering実践例

今回の構成は、ざっくり以下となっています。

ポイントは以下です。

1. エージェントの種類別にシェルスクリプトを用意し、10分毎にcronで起動
2. エージェントの作業別にSkillsを用意し、Spec駆動開発を実施する
3. 各エージェントの種類に応じたIssue/MRのラベルを確認し、動作対象なら claude -p "/sdd-*** Issue/MR番号" というコマンドでエージェントを起動

特に、2のSkillsでIssueやMRの起票を明示する事で、人間はラベルの貼り替えのみでClaude Codeに作業を依頼出来ます。

Skillsの中身も踏まえると、以下のようなフローとなります。

1. 人間: plan::go ラベルを貼る
   • エージェント: Spec作成フローを開始
     • 不明点あり: ユーザへの質問をissueコメントに記載し、plan::question ラベルを貼る
       • 人間は質問へ回答し、plan::go ラベルを貼る
     • 不明点なし: Draft版MRを作成
2. 人間: MRをレビューする
   • 問題あり: エージェントへの改善点をissueに記載し、plan::go ラベルを貼って差し戻す
   • 問題なし: MRに loop::ready ラベルを貼る
3. エージェント: Spec駆動開発フローに従って実装
   • 実装完了後、loop::needs review ラベルを貼る
4. エージェント: コードレビューを実施
   • 問題あり: 指摘をコメント後、loop::change-requested で差し戻す
   • 問題なし: loop::approve ラベルを付与
5. 人間: MRをマージ

6. developパイプライン: ビルド・デプロイ・テストを実施
   • 問題なし: release watcherエージェントが develop -> main MRを作成
   • 問題あり: release watcherエージェントが対応用MRを作成し、loop::change-requested ラベルを付与
7. MRをマージ
   • 問題なし: issueの実装完了
   • 問題あり: release watcherエージェントが対応用MRを作成し、loop::change-requested ラベルを付与

以上です。

結果、人間に残されたタスクは、以下に絞られます。

• 計画を進めたいissueにラベルを貼る
• 開発を進めたいMRにラベルを貼る
• 完成したMRをマージする
• mainへのMRをマージする

これくらいなら、PCの前に座っている必要すら無いですよね。正直、スマホからGitLabにアクセス出来れば十分です。

ちなみに、GitLab Duoはスマホからでも呼べるので、エージェントにトラブルがあって人間が呼ばれても、簡単なものであればDuoに修正依頼出来ます。

Loop Engineeringの実装において重要なポイント

今回ご紹介したものは私のアーキテクチャ例ですが、もちろん他にも様々なパターンがあると思います。どんなパターンでも共通のポイントは、「AIエージェントのガードレールの作り方」です。AIエージェントを自律的に動かそうと思うと、無限ループや本番環境への意図しない作業を防ぐ仕組みが必要です。

今回のケースでは、以下をガードレールとして実装しています。

• 全てのエージェントに、タイムアウトを設定する: 無限ループによるトークンのバーストを防ぐ
• エージェントは必ずSkillsを呼び出し、手順に沿ってSpec駆動開発する: 開発手順をフロー化する事で、予期しない作業を防ぐ
• AWS環境へのデプロイは、パイプラインで行う: エージェントには一切AWS認証情報を持たせない事で、本番環境への影響を防ぐ

特に、エージェントと本番環境の認証情報を分離する事は非常に重要です。開発中のテストにはdockerを使わせて、認証情報が必要な作業はRunbook化してGitLab Runner上で実行する、など、様々な手法が考えられます。ぜひご自分の環境にあった手法を検討してみて下さい。

最後に

最近AI-DLCの伴走支援の引き合いを多数頂くのですが、この領域が最終的にたどり着くのは、AIエージェントによる完全自律稼働だと考えています。
今回Loop Engineeringを実践してみて、AIエージェントを自律稼働させる為の手法の一つとして可能性を感じました。

特にGitLabとLoop Engineeringの相性は非常に良く、この仕組みなら大概のシステムを自動化出来そうです。例えば、定期的にScheduled Pipelineとしてエージェントを起動し、プロダクトのログを分析。改善の為のIssueを作成させ、そのままラベルを貼って開発プロセスに投入する。他には問い合わせ対応をIssueベースにしてもらう事で、FAQのような使い方も出来るかもしれません。個人的には、AWS環境のメンテナンス作業をIssue化して、今回の仕組みで自動化してみようと思っています。

以上です。最後までお読みくださり、ありがとうございました！

AI-DLCの推進にパートナーが欲しいということでしたら、ぜひお気軽にGitLab社 & ソニービズネットワークスまでご相談ください！

お問い合わせはこちら

お問い合わせ内容をご記入ください欄に、https://about.gitlab.com/ja-jp/blog/loop-engineering-gitlab-claude-codeをご覧になったと記入いただくとスムーズです。