LSPを超えたコード理解の革命児「Sem」：Gitベースでコードをエンティティとして捉える新技術

コード解析の常識が変わるかもしれません。「Sem」は従来のLSP（Language Server Protocol）に依存せず、Git上のコードを独自のエンティティとして抽象化・理解する新しいプリミティブ（基本構成要素）です。開発者の体験を根本から変える可能性を秘めたこの技術に注目です。

これってClaude Codeが自分のリポジトリに対して何をしたかを確認するためのもの？

Harness（モデル＋ツール＋スキル）からより良い結果を引き出すために、ソフトウェアの書き方をどう変えるべきか、その微妙な工夫に興味があるんだ。Semを使う場合、特定のコードの書き方をした方が効果的じゃないかと思ってる。

単にコードを小さな関数に分割する以外に、どんな工夫が考えられるか教えてくれない？

例えば、モデルはユニットテストを作成する際、関数内の命令型コードをモックにして再実装するだけになりがちだよね。もしテスト作成エージェントが、関数のdocstring、名前/引数/型、分岐文、ログイベントにしかアクセスできないように制限してビヘイビアテストを強制できれば、こういう質の低いテストが作られるのを防げるかもしれない。でも、そうなるとコード側もそれらの要素から情報をしっかり提供できるように最適化する必要があるよね。

これはあくまで一例で、実際にうまくいくかは自信がないけど。

このアイデアすごく気に入ってるよ。1週間くらい試行錯誤してるんだ。

コードフォージ（コード管理プラットフォーム）で、ユーザーにUI上の行単位のdiffを見せない、あるいは少なくとも最初には見せないようにするためのAST diffシステムにはチャンスがあると思う。

コードレビューはエディタ上で行われるべきだ、っていうのは強く信じてるよ。

ベンチマークがいまいちだね。semの出力に依存しすぎてる。なぜClaudeに対して「コミットによって何個の『エンティティ』が変更されたか」なんて質問をする必要があるの？それに、そんなリクエスト専用のツールが必要なの？ちなみに「エンティティ」っていうのはsem独自の概念だよね…

  $ sem impact authenticateUser

  ⊕ function authenticateUser (src/auth/login.ts:26)

    → depends on:    db.findUser, rateLimiter.check
    ← used by:       loginRoute, authMiddleware
    ! 42 entities transitively affected
    ᛋ 7 tests affected

おっ、これはかなりいい感じだね。人間が見ても有益な情報だよ。

去年、同じようなものを自作しようとして半分くらいまでやったことがあるんだ（git関連は除くけどね）。コードベース内の依存関係グラフを作ろうとしてたんだよ（実際、正規表現でかなりいいところまでいけたんだ！）。

これが人間やエージェントにとっての真の課題を解決しているのか、正直疑わしいな。特に複雑なプロジェクトにおいて。このツールとコマンドが具体的にどう役立つのか、シナリオを見せてくれると助かるんだけど。

いいツールだと思うけど、お願いだからこれだけは削除してほしい：

AIエージェントは、生の行diffよりもsemの出力を使った方が2.3倍正確。ベンチマークを参照。

いや…これは何の説得力にもなってないよ。現実世界のタスクじゃないからね。

自分のツールを使えばAIエージェントのコーディングやバグ修正能力が2.3倍向上するかのように見せかけようとしているけど、実際は違うだろ。

そのベンチマークでは何も証明できていないよ。

ツール自体はクールなんだから、そうでないものとして売るんじゃなくて、ありのままの価値で売り出そうぜ。

ページの最後にある「10秒で試そう」のセクション、既存のツール（git diff）を乗っ取ってpre-commitフックをインストールさせる仕様だよね。

気に入らなかった場合にどうやって元に戻すかの説明がどこにもない。ちょっとユーザーを軽視している感じがして嫌だな。