はじめに
今週もZennやGitHub Blogを眺めていたら、「これ自分の環境でも試せるな」と手を動かしたくなるトピックがいくつか出てきた。特に静的解析によるコードグラフ化・LocalStack有料化への対応・社内AIエージェントの構築・git worktreesは、業務にそのまま応用できそうなテーマだったので実際に触ってみた。
1. 46リポジトリを一つのナレッジグラフに——静的解析の可能性
エアークローゼットのCTOが書いた記事で、46個のリポジトリを静的解析で1つのナレッジグラフに統合した話が話題になっていた。「LLMにコードを読ませる」だけでなく、依存関係を構造化してグラフDBに入れるアプローチが面白い。
うちのチームでも似たような課題があって、マイクロサービスが10個ほど並んでいる中でどのサービスがどのAPIを呼んでいるか誰も把握できていない状態だった。試しにPythonのASTとNetworkXでサービス間の依存グラフを手元で作ってみた。
import ast
import networkx as nx
from pathlib import Path
G = nx.DiGraph()
def extract_imports(filepath: Path):
src = filepath.read_text()
tree = ast.parse(src)
for node in ast.walk(tree):
if isinstance(node, ast.ImportFrom) and node.module:
G.add_edge(filepath.stem, node.module)
for py_file in Path("./services").rglob("*.py"):
extract_imports(py_file)
print(f"ノード数: {G.number_of_nodes()}, エッジ数: {G.number_of_edges()}")
実行してみたら循環依存が3箇所あって、「なんか不安定だと思ってたのここか」となった。小規模でもグラフ化すると見えてくるものがある。46リポジトリで同じことをやろうとすると、パース精度や言語の多様性がネックになりそうで、そこを乗り越えた話の続編が楽しみ。
2. LocalStack有料化——MiniStack + Terraformで移行してみた
2026年3月にLocalStackのCommunity Editionが廃止された。個人開発でS3とSQSをローカルで動かしていたので、代替を探してMiniStackを試してみた。
pip install ministack
ministack up --services s3,sqs
起動自体はすんなりいったが、ハマったのがTerraformのエンドポイント設定。LocalStackはS3もSQSも4566番ポートにまとまっていたが、MiniStackはサービスごとにポートが分かれる。
provider "aws" {
region = "us-east-1"
access_key = "test"
secret_key = "test"
skip_credentials_validation = true
skip_requesting_account_id = true
endpoints {
s3 = "http://localhost:4566"
sqs = "http://localhost:4576" # LocalStackと違いポートが分かれる
}
}
terraform planが通らなくてしばらく詰まったが、ministack statusでポートマッピングを確認してから解決した。機能的には個人開発レベルなら問題なさそうで、移行コストも思ったより低かった。
3. 社内データ分析エージェントを作る——GitHubのQubot事例から
GitHubが社内向けに「Qubot」というCopilot駆動のデータ分析エージェントを構築した話を読んで、自分のチームでも似たものを作れないか試してみた。記事で触れられていた一番難しいポイント——「スキーマの理解をLLMに持たせる部分」——は実際にそのとおりだった。
試しにClaudeのtool useを使ってSQLを生成するシンプルなエージェントを書いた。
import anthropic
client = anthropic.Anthropic()
tools = [{
"name": "run_sql",
"description": "SQLクエリを実行してデータを取得する",
"input_schema": {
"type": "object",
"properties": {
"query": {"type": "string", "description": "実行するSQLクエリ"}
},
"required": ["query"]
}
}]
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
tools=tools,
system="テーブル定義: orders(id, user_id, amount, created_at), users(id, name)",
messages=[{"role": "user", "content": "先週のオーダー数を日別に教えて"}]
)
スキーマ情報をsystem promptに詰め込むとそこそこ正確なSQLが出てきた。ただ、テーブル名のブレ（ordersとorder_historyが混在）には弱くて、エイリアスをちゃんと整理することが精度向上の近道だと実感した。DB設計の品質がそのまま回答品質に直結する。
4. git worktreesを使ったら並行作業が快適になった
GitHub Blogでgit worktreesが取り上げられていた。2015年からある機能なのに最近になって注目されているらしい。自分も最近使い始めたばかりで、確かに便利だった。
# featureブランチを別ディレクトリでチェックアウト
git worktree add ../myapp-feature feature/add-search
# 一覧確認
git worktree list
# 作業後の削除
git worktree remove ../myapp-feature
レビューしながら別ブランチで作業したいとき、今まではstashしてから切り替えていた。worktreeにしてからはエディタを2つ開くだけになって、コンテキストスイッチが減った。インストール不要でgitに組み込み済みなので、試さない手はない。
まとめ
今週試した中で一番インパクトが大きかったのはナレッジグラフ化で、小規模でも依存関係の整理にすぐ使えた。LocalStack移行はポート番号の差異に注意すれば思ったより楽に乗り換えられた。社内AIエージェントはスキーマ品質が直接回答精度に影響するので、DB設計から見直す必要があると気づいた。git worktreesは今すぐ使える改善で、並行作業が多い人には特に効く。
どれも「試してみたら意外と動いた」系のトピックなので、気になったものから手を動かしてみてほしい。