LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@BNR-Shizuka

AIと考える仕事術 | [第8回]: ルーチン業務の自動代行

Posted at

1. はじめに：なぜ今、AIエージェントなのか？

毎日、私たちエンジニアは多くのルーチン業務に時間を取られていませんか？

  • 定期的なログの確認とエラーメールの送信
  • プルリクエストの差分を読んでの初歩的なチェック
  • 社内Wikiやドキュメントからの情報収集と要約
  • スプレッドシートのデータに基づいた定型レポートの作成

これらの業務は重要ですが、創造性を必要とせず、時間に対する対価も低いです。本記事では、Large Language Model (LLM) を中核としたAIエージョントを構築し、このような「定型的で退屈な仕事」を自動化する実践的な手法を解説します。

理論だけで終わらせず、実際に動くコード（Python）と共に、クラウド（AWS）へのデプロイ方法、そして開発の中で私が得た貴重な失敗経験も共有します。最後まで読めば、明日からでも自身の業務を自動化する第一歩を踏み出せるはずです。

2. 技術概要：AIエージェントのコアコンポーネント

今回構築するAIエージェントは、単なるチャットボットではありません。「自律的に考え、行動する」 ことを目的としています。そのための基本的な構成要素は以下の通りです。

  1. LLM (Large Language Model): エージェントの「脳」。OpenAIのGPT-4やClaude 3、あるいはオープンソースのLlama 3などを推論エンジンとして使用します。入力されたタスクを理解し、実行すべきアクションを論理的に考えます。
  2. Tools (ツール): エージェントの「手足」。LLM自体は外部と干渉できません。Web検索、API呼び出し、データベース操作、ファイル読み書きなどの機能は、すべて個別のツールとして定義し、LLMに提供します。
  3. Agent Core (エージェントコア): 「脳」と「手足」を協調させる「神経系」。与えられたタスクに対して、LLMが使用するツールを決定し、その実行結果をまたLLMに渡して解釈させ、次のアクションを決定するループを制御します。LangChainやLlamaIndexなどのフレームワークがこの部分を抽象化して提供してくれます。
  4. Orchestrator (オーケストレーター): エージェントを起動・管理する「舞台監督」。AWS LambdaやStep Functions、FastAPIなどが該当します。スケジュール実行やイベント駆動での起動、モニタリングを担当します。

今回は、開発の容易さと強力な機能からLangChainをエージェントコアに採用します。

3. 実装例：プルリクエスト要約エージェントを作成する

実際に、GitHubのプルリクエスト（PR）の差分を取得し、変更内容を要約し、潜在的なリスクをコメントしてくれるエージェントを構築してみましょう。

環境構築

必要なパッケージをインストールします。

pip install langchain-openai langchain github3.py python-dotenv

ソースコード解説

以下は主要部分のコードです。完全なコードはGitHubリポジトリを参照してください。

import os
from dotenv import load_dotenv
from langchain.agents import AgentType, initialize_agent, Tool
from langchain_openai import OpenAI
from langchain.schema import SystemMessage
import github3

# 環境変数の読み込み (OpenAI API Key, GitHub Token)
load_dotenv()

def get_github_pr_diff(repo_owner, repo_name, pr_number):
    """
    GitHubのPR差分を取得するTool用の関数
    """
    gh = github3.login(token=os.getenv('GITHUB_TOKEN'))
    repo = gh.repository(repo_owner, repo_name)
    pr = repo.pull_request(pr_number)
    return pr.diff()

def analyze_pr_diff(diff_text):
    """
    PR差分を要約・分析するTool用の関数
    """
    # この関数はLLMエージェント自身が呼び出すため、中身はほぼ空で良い
    pass

def main():
    # 1. LLMの設定 (gpt-3.5-turbo-instructやgpt-4を指定可能)
    llm = OpenAI(model_name="gpt-3.5-turbo-instruct", temperature=0)

    # 2. Toolの定義
    tools = [
        Tool(
            name="Get_PR_Diff",
            func=lambda inputs: get_github_pr_diff("my_org", "my_repo", 123), # パラメータは固定またはエージェント外で処理
            description="GitHubの特定のプルリクエストの差分(diff)を取得するために使用します。入力は必要ありません。"
        ),
        Tool(
            name="Analyze_Diff",
            func=analyze_pr_diff,
            description="PR差分のテキストを受け取り、変更内容の要約と潜在的な問題点を分析します。入力は差分テキストです。"
        )
    ]

    # 3. エージェントのシステムメッセージ（役割の定義）
    system_message = SystemMessage(content="あなたは優秀なシニアソフトウェアエンジニアです。GitHubのプルリクエストを分析し、以下のことを日本語で行ってください。1. 変更内容の要約 2. 潜在的なバグやパフォーマンス問題の指摘 3. コードスタイルの確認")

    # 4. エージェントの初期化
    agent = initialize_agent(
        tools,
        llm,
        agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, # 思考と行動を繰り返すエージェントタイプ
        verbose=True, # 思考過程をコンソールに出力（デバッグに極めて重要）
        agent_kwargs={
            "system_message": system_message,
        }
    )

    # 5. エージェントの実行
    prompt = """
    GitHubリポジトリ 'my_org/my_repo' のプルリクエスト #123 を分析してください。
    Get_PR_Diffツールを使って差分を取得し、Analyze_Diffツールを使って分析してください。
    分析結果は最終的に日本語でまとめてください。
    """
    result = agent.run(prompt)
    print(f"\n=== 分析結果 ===\n{result}")

if __name__ == "__main__":
    main()

実行結果例

verbose=True による思考過程のログは以下のようになります。

> Entering new AgentExecutor chain...
 まず、PRの差分を取得する必要がある。Get_PR_Diffツールを使おう。
> Get_PR_Diffツールを呼び出します...
> 呼び出し結果: diff --git a/app.py b/app.py ... (実際のdiffテキスト)

 差分を取得したので、次にこの差分を分析する。Analyze_Diffツールを使おう。
> Analyze_Diffツールを呼び出します...
> 呼び出し結果: (この結果は実際にはanalyze_pr_diff関数の戻り値ではなく、LLMの分析結果が直接出る)

 分析が完了した。結果をまとめる。
> 最終的な回答を生成します。

=== 分析結果 ===
**プルリクエスト #123 分析レポート**

【変更内容の要約】
・ユーザー登録API (app.py) にメールアドレスのバリデーション処理を追加
・新規モジュール `validator.py` を作成し、メールアドレス検証ロジックを実装

【潜在的な問題点】
1. **セキュリティ**: 追加された`validator.py`で正規表現を使用していますが、非常に複雑なパターンのため、メンテナンス性とパフォーマンスに懸念があります。ReDoS攻撃のリスクを考慮すべきです。
2. **パフォーマンス**: 毎回のリクエストでこの正規表現が実行されます。バリデーション失敗時のエラーメッセージが詳細すぎるため、ユーザーに過剰な情報を提供している可能性があります。

【コードスタイル】
・全体的に可読性は高いです。ただし、`validator.py`の関数にはdocstringが不足しています。

4. 実践的なTipsとよくある落とし穴

実際にプロダクションで運用する上で得た知見を共有します。

  • Tips 1: プロンプト設計は「役割」と「フォーマット」を明確に

    • SystemMessage でエージェントの専門性や役割を強く設定します（例: 「あなたはクラウドセキュリティの専門家です」）。
    • 出力フォーマットを指定すると後工程の処理が楽になります（例: 「最終出力はJSON形式で、summaryとrisk_levelキーを含めること」）。

  • Tips 2: Toolの設計は細かく・具体的に

    • Get_PR_Diff と Analyze_Diff を分けたように、ツールは抽象的すぎず、具体的なアクションに分割します。LLMは小さなステップの積み重ねが得意です。
    • description は非常に重要です。LLMはこの説明だけを頼りにツールの使い方を判断します。自然な文章で「何をするツールなのか」「入力と出力は何か」を明記してください。

  • 落とし穴 1: 無限ループと高いAPIコスト

    • エージェントが思考ループに陥り、何度も同じツールを呼び出し、APIコストが膨らむ事故が発生します。
    • 対策: max_iterations パラメータで思考回数の上限を必ず設定する。AgentTypeによってはZERO_SHOT_REACT_DESCRIPTIONより制御しやすいものもあるので、ドキュメントを読みましょう。

  • 落とし穴 2: トークン数の爆発

    • 差分のテキストなど、長大なコンテキストをLLMに送ると、トークン数が増え、コストとレイテンシーが跳ね上がります。
    • 対策: 要約するなどしてコンテキストを圧縮する「Map-Reduce」などの手法を検討する。あるいは、Claudeなどのコンテキスト長が長いモデルを選択する。

  • 落とし穴 3: エラーハンドリングの不足

    • ToolのAPI呼び出しが失敗した場合、エージェントは意味のわからないエラーメッセージを食べてしまい、デバッグが困難です。
    • 対策: 各Tool関数内で徹底した例外処理を行う。エラーメッセージをLLMが理解しやすい形で返す（例: ERROR: API call failed with status code 404）。

5. 応用と発展：クラウドへのデプロイと他のユースケース

AWS Lambdaへのデプロイ

このスクリプトをcronジョブで定期実行させるには、AWS Lambdaが適しています。その際のポイントは以下です。

  • レイヤーの活用: LangChainやGitHub3.pyなどの依存パッケージをZipで固めてLambdaレイヤーとして登録します。
  • 環境変数の暗号化: OpenAI APIキーやGitHubトークンはAWS Systems Manager Parameter StoreやSecrets Managerで安全に管理し、Lambda関数から参照します。
  • トリガーの設定: イベントブリッジ（EventBridge）でcron式（例: cron(0 18 ? * MON-FRI *)）を設定し、平日の夕方に自動実行されるようにします。

他の自動化アイデア

  • S3レポート要約エージェント: 每日S3にアップロードされるCSV銷售レポートを取得し、主要KPIのトレンドと外れ値を検知してSlackに投稿する。
  • CloudWatchログ監視エージェント: 特定のエラーパターン（例: 5xxエラー）をログから発見し、その周辺のコンテキストを要約してPagerDutyでインシデントを起動する。
  • ドキュメント質問応答エージェント: 社内の膨大な設計書やマニュアルをベクトルデータベースに格納し、自然言語で質問できるQ&Aボットを構築する（LlamaIndexの出番です）。

6. 結論

メリット

  • 生産性の向上: 単純作業から解放され、より創造的なタスクに集中できる。
  • 24時間365日稼働: 疲れ知らずのアシスタントが深夜や休日も作業を進めてくれる。
  • 知識の標準化: 優秀なエンジニアの判断基準をエージェントに埋め込み、組織全体の知識レベルを底上げできる。

デメリット（課題）

  • 開発・テストコスト: プロンプトの調整やツールの開発には想像以上に時間がかかる。
  • 予期せぬ動作: LLMは時に驚くほど創造的であり、驚くほど愚かな出力をすることがある。ヒューマンオーバーループ（最終的な判断は人間が行う）の仕組みが必須。
  • コスト管理: API呼び出しコストは無視できないため、利用量のモニタリングと予算アラートの設定が重要。

未来展望
LLMの性能は急速に向上し、ツールの呼び出し精度も高まっています。また、エージェント開発を大幅に簡素化するフレームワーク（MicrosoftのAutoGen、Camel.aiなど）も登場しています。今後は、単一タスクの自動化から、複数の専門性を持つエージェントが協調して複雑なプロジェクトを推進する「マルチエージェントシステム」が一般的になるでしょう。

まずは小さなタスクからで構いません。あなたの日常の「面倒くさいこと」を一つ取り出し、AIエージェントにやらせてみてはいかがでしょうか。その実践が、最も良い学びになります。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?