lx: 開発者が完全に制御できるバイブコーディングツール

(github.com/chebread)

7 ポイント投稿者 chebread 2026-01-29 | 12件のコメント | WhatsAppで共有

序論

こんにちは。コンピュータ工学に興味のある学生です。今回、lx というプログラムを開発したので、読むだけだった GeekNews に初めて投稿してみようと思います。

最近は、AI に自然言語で命令するとコードを勝手に全部書いてくれるバイブコーディングが主流です。
私はこうしたバイブコーディングに恐怖を感じています。
単なる失業への不安ではなく、「コードを書く楽しさ（Wrangling code）」（出典: ケント・ベック - Augmented Coding: Beyond the Vibes）と「開発者の制御権」が奪われつつあることによる、プログラミングの喪失感のためです。

この変化を、パンチカードから機械語、アセンブリ言語、C 言語へと続くプログラミングの自然な進化だと言う人もいます。ですが私は、このたとえは間違っていると思います。
過去の抽象化は、開発者に「より良いハンマー」を握らせる過程でした。
道具は進化し続けても、ハンマーを振るう主体は依然として人間であり、結果は完全に開発者の制御下にありました。
しかし、今の AI コーディングは違います。
今ではロボットが代わりにハンマーを振るい、開発者はただ眺めるか、せいぜいロボットを少しなだめてみるだけの立場になっています。
私たちがハンマーを振るえないなら、それはもはやプログラミングとは言えないと思います。
なぜなら、それは全面的に私たちの制御下にないからです。

だから私は lx を作りました。
lx はロボットからハンマーを取り戻し、再び開発者の手に握らせるためのツールです。
lx は AI を徹底的に制御可能なツールとして扱えるようにします。

本論

lx は「インターフェースは人間が、ロジックは AI が」という哲学を持っています。
開発者は関数の入力・出力と、その関数が何をするかを定義して「契約」を結び、AI はその関数の内部実装だけを担当します。

このアプローチは、開発の連続性を保証します。
関数の入力・出力を書いた瞬間、そのロジックはすでに完成したものと見なされます。
プログラマは細部の実装に埋没せず、すぐに上位ロジックを書き進められるため、開発の流れを途切れさせません。

また lx は単なるテキスト置換ではありません。github.com/tree-sitter/go-tree-sitter パッケージを活用し、AST（抽象構文木）ベースでソースコードをパースします。そのため、ファイル内の他のコード、コメント、インデントを汚染せず、指定されたスコープのロジックだけを安全に置き換えます。

基本的な使い方

lx を使う基本的な形は次のとおりです。

package main  
  
import (  
	"fmt"  
  
	lx "github.com/chebread/lxgo"  
)  
  
func main() {  
	var year string = "2025-01-02"  
    // 開発者は関数呼び出し側とフローを制御します。  
	result1 := LX_GetYear(year)  
  
	var age = 30  
	result2 := LX_GetAge(age)  
  
	fmt.Println(result1, result2)  
}  
  
func LX_GetYear(year string) (result string) {  
	// AI に渡すプロンプト  
	lx.Generate("yyyy-dd-mm 形式を韓国式の日付に変換")  
	return  
}  
  
func LX_GetAge(year int) (result string) {  
	// プログラミング言語ごとに lx ライブラリを別途インストールするのが面倒な場合のために、以下のような lx() コメントマーカー形式にも対応しています。  
    // lx("韓国式の年齢を満年齢に変換")  
	return  
}

上のコードで LX_GetYear 関数は、開発者が定義した契約です。
lx ツールを実行すると、このツールは lx.Generate(...) または // lx(...) マーカーを認識して LLM にプロンプトを送り、その関数の本体を実際に動作するコードで上書きします。

このとき、トークン最適化が適用されます。ファイル全体を送るのではなく、その関数のシグネチャとプロンプトだけを LLM に送ることで、コストを削減し、セキュリティも強化します。

2. 開発者の制御

lx 関数内部のロジックは AI が書きますが、その関数を使う主体は開発者であるべきです。
ただし、lx 関数の内部にユーザー定義ロジックを混ぜても無視されるため、以下のようにラッパー関数を通して制御できます。

package test  
  
import (  
	"fmt"  
	lx "github.com/chebread/lxgo"  
)  
  
func main() {  
	var year string = "2025-01-02"  
	result1 := ParseYear(year) // ラッパー関数を呼び出し  
  
	fmt.Println(result1)  
}  
  
// 開発者が制御するビジネスロジック  
func ParseYear(year string) string {  
    // AI が生成したロジックを部品のように利用  
	res := LX_GetYear(year)  
    
    // 結果に対する追加加工は開発者の役割  
	foo := fmt.Sprintf("今日は %v です!", res)  
	return foo  
}  
  
func LX_GetYear(year string) (result string) {  
	lx.Generate("yyyy-dd-mm 形式を韓国式の日付に変換")  
	return  
}

3. 安全な依存関係管理と透明性

lx は単一責任原則（SRP）を志向します。
コードを生成するだけで、プログラムをビルドしたり実行したりはしません。
また、AI が生成したコードに外部ライブラリが必要な場合でも、lx は勝手にパッケージをインストールしません。

Code: 生成されたコードの先頭に // lx-dep: ... コメントを明記
Output: CLI 標準出力でインストールが必要な一覧をレポート

代わりに、この 2 つの方法で開発者に報告します。
開発者はそれを確認して、依存関係を自分でインストールするかどうかを判断できます。

4. 設定

lx を使うには LLM の設定が必要です。ホームディレクトリ（~/）またはプロジェクトルート（./）に lx-config.yaml を作成すればよいです。もし両方のパスにファイルがある場合は、ローカル設定ファイルが優先適用されるため、各プロジェクトごとに lx の設定を別々に管理できます。

# lx-config.yaml  
provider: "gemini"  
api_key: "foo"  
model: "bar"

5. インストールと実行

Mac ユーザーは Homebrew 経由でインストールでき、その他の OS では lx の GitHub Releases からバイナリをダウンロードしてインストールできます。

brew tap chebread/lx  
brew install lx

インストール後、プロジェクトのパスで lx コマンドを実行すると実際のコードが生成されます。
lx にはスマート生成機能があり、すでにコードが生成された関数では再び LLM を呼び出さないため、安心して lx コマンドを繰り返し実行できます。

参考: lx は生成されたコードのフォーマットのために、各言語ごとのツール（Go: goimports, Python: ruff, JS: prettier）を使用します。これらのツールは事前にインストールされている必要があります。

6. ライセンス

lx は AGPL-3.0 License の下で配布されます。
lx がオープンソースのエコシステムに貢献しつつ、このツールがクローズドに私有化されることを防ぐためです。

結論

ソフトウェアは人間の絶え間ない努力によって織り上げられた結晶です。AI 時代においても、プログラマは依然としてコードの主人であるべきです。
lx は面倒な正規表現やデータパースのような「退屈な実装」は AI に任せつつ、プログラムの構造と流れは人間が完全に所有できるようにしてくれます。
コードを書く楽しさ（Wrangling code）と制御権を失いたくない開発者の方々に、このツールをおすすめします!

12件のコメント

moderator 2026-01-31

運営ポリシーに基づき、不適切なコメントは削除され、当該アカウントの利用は制限されました。

callakrsos 2026-01-30

今のコーディングも結局は人間基準なので、
将来は非効率な人間基準の言語ではない形で開発されるようになる気がします。
今は人間基準のフレームワークを大いに楽しみましょう

galadbran 2026-01-31

最近の「コードをまったく見ないほどうまくできる」という風潮とは正反対のアプローチなので、とても興味深いです。
選び方によっては、AI が触る領域を明確に区切ってくれる感覚で使うこともできそうですね。
コーディングエージェントたちのスキルとして作ってみるのも悪くないかもしれませんね？

chebread 2026-01-31

積極的に検討します。ご関心をお持ちでしたら、ぜひ多くのPRをお願いします！

narubrown 2026-01-30

面白いプロジェクトですね！

Ix仕様を書いて -> Ix Toolでlx関数を本物の関数に置き換えて -> goでコンパイルするんですね。
lxを使うレイヤーがプロジェクト内にできることで、
LLMで書かれた層を分離できそうなので、あとで保守するときも楽にできそうです。

LLMを使った興味深い試みですね！

chebread 2026-01-30

ありがとうございます。lx は Go 言語以外の言語にも対応していますので、ぜひご活用いただき、ご意見やアドバイスをお寄せください！

iknowca 2026-01-30

目標は興味深いのですが、本文全体からAI特有の文体が強く感じられて、
信頼しにくいですね。

chebread 2026-01-30

ご指摘ありがとうございます。私は高校生なので、あまり時間がなく、AIを活用して文章を書いていたため、信頼性がかなり低い内容の文章になってしまいました。少し不快に感じられるかもしれませんが、どうかご容赦ください。

wegaia 2026-01-31

わあ、高校生がこんなものを考案したなんて本当にすごいですね。
経験をさらに積めば、もっとすごいものを作れそうです。

siabard 2026-01-30

lx.Generate を呼び出すコードが、コマンドラインから命令を出すと LLM が書いたコードに変更される、という方式で合っているのでしょうか?
呼び出し部分が一種の型制約になり得るという点は、良いアイデアのように思います。エディタなどで lx コマンドが自動実行され、実装コードを置き換えてくれる方式も検討されているのか気になります。（あわせて、生成されたコードが気に入らないときに再生成する方法があると良さそうです。）
プロジェクト、興味深く拝見しました。

chebread 2026-01-30

lx.Generate を呼び出すコードが、コマンドラインから命令を出すと LLM が書いたコードに変更される仕組み、という理解で合っていますよね？ -> はい、その通りです！

呼び出し部分が一種の型制約になり得る点は良いアイデアだと思います。エディタなどで lx コマンドが自動実行されて実装コードを置き換える方式も検討されているのか気になりますね。 -> 本当に良いアイデアだと思います。前向きに参考にさせていただきます。

あわせて、生成されたコードが気に入らないときに再生成する方法があると良さそうです。 -> プロジェクトの哲学が開発者の統制下にある人工知能であるため、再生成が必要な場合は再び lx マーカーを生成するように設計しました。

maneuling 2026-01-30

幼い高校生が作ったものを見て、必死に這い込んできて残すコメントの程度を見れば、知能レベルも察しがつきますね。

鏡を見て少しは治療してください。

killdong | 9か月前 | parent | on: 私は自分のサーバーを守るためにZIP爆弾を使う (idiallo.com)
インターネットでも排泄のような書き込みに責任を取らないなら、インターネットの使用を禁止すべきだと思います。吐き散らかしたものは少しは始末してください.

lx: 開発者が完全に制御できるバイブコーディングツール

序論

本論

基本的な使い方

2. 開発者の制御

3. 安全な依存関係管理と透明性

4. 設定

5. インストールと実行

6. ライセンス

結論

関連記事

12件のコメント