LLMベースのコード規約リンターを作りました。
(github.com/DevSymphony)こんにちは！ 私たちは sym-cli を開発している大学生チーム、シンフォニーです。
最近、Cursor や Claude Code のようなツールを使ってバイブコーディングをよくしていますか？ 私たちのチームも開発の過程で LLM を積極的に活用しています。ところが、使っているうちに一つ物足りない点がありました。
AI が書いたコードは機能的にはうまく動きますが、私たちのチーム独自の規約（変数の命名規則、コメントのスタイル、特定ライブラリの使用ルールなど）を何度も無視してしまうのです。毎回プロンプトにルールを書くのは面倒ですし、使っているうちにだんだん規約自体を忘れてしまう問題もありました。
そこで、"LLM がコードを書く前、あるいは書いている途中で、自分で規約を確認できないだろうか？" という発想から sym-cli を作り始めました。
[sym-cli とは？]
sym-cli は AI コーディングツール向けのポリシーベースのコード規約リンターです。核心は、MCP を活用して LLM と直接やり取りする点にあります。
既存のリンターとの違いは次のとおりです。
- (自然言語ベースの設定) 複雑な設定ファイルの代わりに、"絶対に log を print で書かないで" のように自然言語でルールを定義すると、LLM がそれを理解して従います。
- (コンテキスト最適化) LLM がプロジェクト内のすべてのルールを読むのではなく、MCP ツールを通じて現在の作業に必要なルールだけを賢く取得します。
- (能動的な検査)
validate_codeツールを通じて、LLM がコードを生成した直後に自らルール遵守の有無を検査できます。
[どのように動作しますか？]
sym コマンドをダウンロードした後、sym init コマンドを実行すると MCP サーバー設定が自動で構成され、MCP をサポートする IDE（Cursor など）や LLM ツールでただちにこれらのルールを参照し始めます。
[フィードバックをお願いします！]
私たちはまだ大学生チームで、プロジェクトもようやく骨格ができた初期段階です。至らない点も多く、バグがあるかもしれません。ですが、現場の開発者の皆さんや LLM ツールに強い関心を持つ方々からの応援とフィードバックを切実に必要としています。
"こんな機能があるといい", "この部分は構造的に問題がありそうだ", "実際の現場ではこう使う" など、どのようなご意見でもありがたく受け止めます。オープンソースなので、貢献や GitHub Star は私たちのチームにとって本当に大きな力になります！
GitHub Repository: https://github.com/DevSymphony/sym-cli
npm: npm install -g @dev-symphony/sym
読んでいただきありがとうございます。
7件のコメント
opencodeを使えば、lint機能までワークフローに組み込めます。
https://ja.news.hada.io/topic?id=21883
https://opencode.ai/docs/formatters/
同感です。構文・型エラーのように即座に検出できるものは、LSP やコンパイル段階で扱うのが最も効率的で、トークン使用量の面でも適切なアプローチだと思います。私たちも、LLM がこれを置き換えるというよりは、自然言語で書かれたルールを既存の lint/test ワークフローに自動で接続する役割に近いと考えています。
私もt7vonnさんのように、コンベンションは自動化ツールでそろえるのが正しいと思っていますが、
LSPの機能はかなり違いを感じます。testやコンパイルを回してみないと分からない構文エラーをその場で修正できるので、トークン使用量が減るんですよね。
PRレビューエージェントにコンベンション文書とdiffを渡して抜けている部分を探す程度なら、今でもすでにやっていますし……
それ以上は使わない気がします。
私と似た意見を持つ人の文章を添付します。
おっしゃる利用方法が、現時点では最も現実的なアプローチだと考えています。私たちが解決したい問題は、PRごとに規約文書を渡すプロセスを減らし、自然言語で定義されたルールをあらかじめリンター・検証ルールへ変換して、PR/CI段階で自動実行できるようにすることです。
うーん、なんというか
claudeの hooks/subagents/skill みたいな機能で作ることもできそうですね……技術的には hooks や subagent でも実現できそうですが、私たちは特定の LLM に依存しないよう、MCP と既存のリンターワークフローの上に薄いレイヤーを置く方法を選びました。そのため、エージェント機能そのものよりも、規約を再利用可能なインフラにすることに重点を置いています。