はじめに
はじめまして、高知大学人文社会科学部人文社会科学科4年の坂下康信です。2026年8月3日から9月11日まで、LINEヤフー株式会社のLINEギフトのSRE業務を担当するチームでインターンに参加しました。
本稿では、インターン期間中に取り組んだリリース作業の効率化やAI活用における周辺環境の改善について紹介します。あわせて、AIを活用するための基盤づくりについても取り上げます。
SRE（Site Reliability Engineering）チームのミッションは、開発のスピードを高めつつ、システムの安定性と信頼性を担保することです。近年、生成AIの台頭によってコードを書く速度が飛躍的に向上しています。その反面、アラートの一次調査やブランチ運用、コード規約の違反修正といった周辺プロセスが新たなボトルネックになりつつありました。また、AIを活用する上で、AIが引き起こす不確実性に起因する安全性の担保に課題意識がありました。
これらは従来、開発者が自身のローカルPC上でAIを起動しプロンプトを入力することで対応していました。しかし、LINEヤフーが掲げるバリューの1つである「スピード10倍」を実現するには、個人の作業領域を超えてプラットフォーム側でこれらの処理を自律的かつ自動的に実行する仕組みが欠かせません。
こうした課題に対してインターンではAIを活用して開発を進めていくための各種改善に取り組みました。
リリース作業の効率化
リリース作業における負担軽減のため、機械的に解決可能なバックマージの自動化に取り組みました。
バックマージとは
バックマージとは main ブランチに蓄積された最新の変更を、稼働中の他のブランチへ伝播させる作業です。
LINEギフトでは、リリース日ごとにリリースブラ ンチを作成し、開発者はそこに向けて feature ブランチからPull requestを出します。リリース当日、このリリースブランチが main にマージされることで本番反映となります。
この運用の特性上、リリースブランチは常に main より古い状態になります。リリースのたびに main へ新しいコミットが追加されるため、次のリリースブランチや開発中のブランチへ main の変更を取り込むバックマージが不可欠となります。
ここまでの流れを図にすると、次のようになります。
GitHub Actionsによる自動化
リリース作業は事前確認や検証手順が多く、負担の大きい工程です。main ブランチへのマージを行い、無事に本番への反映作業を終えて一息つきたいタイミングで、リリース担当者がバックマージまで担う運用は、大きな負担となっていました。
しかしバックマージの作業自体はPull requestを生成してマージする定型的かつ機械的なプロセスであり、自動化の適性が高い領域です。
実装の詳細は割愛しますが、GitHub Actionsを毎朝起動し、main の変更を稼働中のすべてのブランチへ取り込むPull requestを自動で作成・マージするパイプラインを構築しました。機械的な判断が適さないクリティカルな領域では、AIが状況を調査し、 必要な対応を具体的に提示する仕組みを組み込みました。
日常的なバックマージから手作業を大きく減らす設計になりました。判断を要する箇所は、手作業の確認を挟む運用にしています。
AIを活用した開発環境の改善
バックマージの自動化を進める中で、AI開発を補助するツールの改善も行いました。
AIに任せる作業を増やすほど自動化が進み、全体の速度が上がりますが、任せる範囲を広げるほど、AIを用いた各種リスクにいかに対処するのかという問題が出てきます。自律的なAIを用いた開発という観点からは、AIへのフィードバックループが重要になるため、テストや静的解析などによって行われる機械的な検出をより充実させたいという課題意識がありました。
今回は稼働していたE2Eテストに着目し、テストの網羅性や検出力を数値化するためにミューテーションテスト（Mutation Testing）の手法を取り入れました。さらに、OpenAPIの整備なども進め、テストの検出力や信頼性そのものを高めることで、より安心して開発ができる環境づくりに貢献しました。
AIの意図しない出力の混入を防ぐための仕組みに、Lefthookを導入しました。これにより、コミットやプッシュの前に自動でチェックを実行できるようになりました。
こういった開発を進める中で、既存ツールの多くがシェルスクリプトによる実装であり保守性に課題があることも見えてきたため、並行して各種ツールをPythonとGoへ移行しました。
単一の言語に統一するのではなく、適材適所での採用を意識しました。Lefthookと連携してローカル環境で高速・安全に動かしたいCLIツールには、単一バイナリで配布できるGoを採用しました。データの分析やAI周辺の柔軟な処理にはPythonを選定しました。対象のリポジトリには日々多くの変更が加えられるため、実行前にできるだけ多くの制約を機械的に検証できることが重要でした。型を活用した開発と静的チェックの徹底、そして環境構築に依存しない高い可搬性を確保できたことで、ツール自体の保守性も向上しました。
ここまでの取り組みによって、定型作業を自動化し、AIが生成した変更を機械的に検証する仕組みを整えることができました。しかしこれらは基本的に、人間がAIへ指示をすることが前提です。そこで、都度プロンプトを入力せずともイベントを契機に自動でAIが状況を把握し、調査を始めるような、AIをシステムに組み込んだ自動化を行うことを目標に取り組みました。
AIの自律化
最後に紹介するのは、従来は個人のローカル環境で行われていたアラートの一次調査やテスト失敗時の原因探求を、AIによって自動化する取り組みです。
なぜハーネスが必要か
AIの自律性を高めるほど、無限ループによる無駄なAPIコールや、意図しない設定変更・書き込みといった不確実性が顕在化します。
ここでは、人間が都度指示をしなくてもAIが処理を完了できる自律的な状態を目指しました。この不確実性に対して、実行ステップ数やタイムアウトの上限を設ける停止条件の厳格化と、ログやメトリクスの参照は許可しつつ破壊的な操作はブロックする権限および環境の分離を仕組みとして組み込みました。
つまり、AI活用基盤を 作ることは、単に高性能なモデルを導入することではありません。AIが失敗しても被害を限定できる環境と、失敗に気づくためのフィードバックを用意し、人間が意図した範囲で能力を発揮させることが重要です。そこで、AIを安全かつ効果的に動かすためのガイド（ハーネス）を整備する取り組みとして、将来のAI活用を支えるハーネスエンジニアリングに着手しました。
技術選定
AIを自律的に動かすシステムを構成するにあたり、まずは仮想マシン上でClaude CodeやCodex CLIといった既存のツールをそのまま起動する構成を検討しました。手軽に構築できる反面、現在は各種ツールやモデルの動向・標準が急速に変化している段階です。特定のツールや環境に強く依存した設計では、将来の標準が変わった際の乗り換えが難しくなり、早期に技術スタックの陳腐化を招くリスクがありました。
また選択肢として、LangGraphなどのエージェントフレームワークの採用や、LLMの公式SDKを直接組み込む構成も検証しました。しかし、SDK直接呼び出しでは会話履歴や状態管理のロジックが自前実装で肥大化しやすく、一方で重厚なフレームワークは学習コストやシステム全体のオーバーヘッドが大きくなるというトレードオフがありました。
そこで、特定のモデルやツールに依存せず、将来的なツールの進化にも追従できる抽象度を保ちながら、会話コンテキストや状態管理を軽量なモジュールとしてシンプルに扱えることを重視して選定しました。
これらの要件とトレードオフを比較検証した結果、エージェント処理をコード上でシンプルかつ明瞭に定義できる "The Open Agent Framework" である flue を採用しました。
システム構成と実装
flueを採用することで、AIのエージェント処理をあたかも1つの関数のようにコード内で宣言的に記述できます。
function TriageAgent({ id }: { id: string }) {
return `Investigate GitHub issue #${id} and recommend the next action.`;
}
ただし関数として扱えたとしても、APIでLLMを呼び出すだけでは文字列が返ってくるに過ぎません。AIに自律的な調査をさせるためには、AI専用の実行環境と安全に利用するためのガードレールをインフラとして用意する必要があります。
最終的に構築したアーキテクチャの概念図は以下の通りです。
AIを自律的に動作させるにあたり、万が一、なんらかの不備によって実行環境が破壊されても被害を限定できるよう、すべての処理をコンテナ内部に隔離しました。また、flueが持つデータベース接続機能を活用し、スレッドごとの会話履歴や調査コンテキストを保持できるようにしました。アラートやテスト失敗の調査には定型的な部分が多いため、これまで暗黙知となっていた調査の知見をAIが参照・活用できる仕組みも整えました。
イベント駆動によるAIの自律運用
ハーネスを構築することで最も大きく変わるのは、AIのイベ ント駆動化です。
人間が手動でプロンプトを入力するのを待つのではなく、社内の監視システムが発するアラートやE2E（End-to-End）テストの失敗通知を契機として、AIが自動で一次調査を開始します。
アラートが発生すると、AIが即座に影響箇所のコードやログ、メトリクスを照合し、原因の見立てや確認ポイント、推奨される次のアクションをSlackスレッドへ自動で返信します。人間が行うのは、提示された調査結果の確認と実際の対応の判断です。
実際の通知の様子は以下の通りです。
おわりにと今後の展望
今回のインターンでは、手順を明確に定義できる定型作業は機械的に自動化し、状況に応じた判断が必要な部分はAIに任せました。並行して、開発における周辺環境を整備することで、AIの自律性とシステムとしての予測可能性の両立を目指しました。
一見すると個々の取り組みは異なりますが、AIの自律性を可能な限り高めながら、不確実性は仕組みで排除し安全性も担保するという方向性を一貫して意識していました。
さて、今回のインターンでは多くのことに挑戦させていただきましたが、時間の制約もあり、いくつかの取り組みにはさらなる改善の余地が残っています。
バックマージの自動化は日々の運用負荷を減らすための取り組みですが、本質的には、バックマージを必要としないブラ ンチ戦略へ移行することが最終的な理想です。ただし、運用の根本的な見直しには抜本的な改修が伴うため、段階的に改善を重ねながら、実質的な移行につなげていきます。
運用改善のためにも、サービスの安全性をテストの観点から支えるE2Eテストの拡充や、開発支援の改善にも引き続き取り組みます。AIによる開発速度の大幅な向上という新たな局面を迎えた時代だからこそ、決定論的な自動化や保証は今まで以上に重視する必要があります。今回は機械的なチェックやテストによる品質保証に取り組みました。ほかにもさまざまな観点が存在し手法も移り変わっていくものであるため、今後はより多角的に品質を保証できるような仕組みづくりを進めていきます。
また、今回構築したAIハーネスは汎用性を備えています。今回は時間の都合上ここまでとなりましたが、将来的にはSlackを起点としたリモートコーディング支援、各種タスクのPull requestの自動作成、関連する課題チケットの自動起票などへ広げていきます。ハーネスを起点にAIを活用し、新しい開発者体験を生み出すプラットフォームへと進化させることが次の目標です。
またこのチームで働く機会があれば、これらの課題にさらに深く挑戦し、「スピード10倍」を揺るぎないものにするプラットフォームを作り上げたいです。
最後になりますが、本インターンを通じて刺激的でやりがいのあるテーマに挑戦する機会をいただき、多くの方々に支えていただきました。とくにメンターの津田さんには、日々の相談から技術的な検討や実装の進め方に至るまで、ほとんどつきっきりで伴走していただきました。また、上長の木本さ んにも、取り組みの方向性や課題への向き合い方について親身にご指導いただき、安心して挑戦を重ねられる環境を整えていただきました。お二人をはじめ、チームの皆様は、高い専門性を持ちながらも議論や試行錯誤を心から楽しむ姿勢が印象的でした。そのような皆様とともに働けた時間は、技術面だけでなく仕事への向き合い方を学ぶ上でも大変貴重な経験となりました。そして、チームの枠を超えて業務を支え、温かく迎えてくださったLINEギフトの皆様や関係者の皆様にも、多大なるご支援をいただきました。この場をお借りして、心より感謝申し上げます。
メンターからの一言
坂下さんのメンターを担当した津田です。
この記事では、インターン期間中に坂下さんが取り組んだバックマージの自動化と、AI活用基盤の構築について紹介しました。
坂下さんは、機械的に解決できる課題から着手し、最終的にはAIが自律的に一次調査を始める基盤の構築まで、一連の流れをやり切ってくれました。とくに印象的だったのは、AIを使った開発の手慣れ具合です。人がAIに指示を出すところで止まらず、イベントを契機にAIが動き出す形まで設計を進めたのは、日頃からAIを道具として使い込んでいるからこその発想だと感じました。
技術選定の過程も印象に残っています。既存のCLIツールをそのまま動かす構成、エージェントフレームワークの採用、LLMのSDKを直接組み込む構成の3つを比較し、将来の乗り換えやすさまで含めて判断していました。開発プロセスの改善に必要な知識やトレンドを日頃から追えていなければ、この短期間でここまでの比較はできなかったはずです。
加えて、行動の速さが際立っていました。課題が見えてから形になるまでが早く、バックマージの自動化、開発環境の整備、AI活用基盤の構築という3つの取り組みを6週間ほどでやり切っています。既存の運用に手を入れることにも物怖じせず、リリース担当者が長く抱えていた負担に正面から取り組んでくれました。
そして何より、取り組みへの情熱が一貫していました。目の前の課題を片付けるだけでなく、その先にある「開発のスピードをどう上げるか」という問いを自分のものとして考え続けてくれたと感じています。
またお会いできることを楽しみにしています！
