Teruhiro Komaki

@teruhirokomaki.bsky.social

家族とプログラミングが好きなエンジニア。 業務システムの開発と、AIエージェントを活用した内製化支援をしています。完成品を作るだけでなく、社内に技術的な判断力と、継続して改善できる仕組みを残すことを大切にしています。 AI Agent / Angular / Cloudflare / Database / Terminal / Debian 気になった技術は、まず自分で動かして確かめるタイプです。

「オープンウェイトモデルなら、高スペックなMacを買えば快適に使える」 くらいの理解の人が多い気がする。 実際には、モデルの総パラメータ数、アクティブパラメータ数、量子化方式によって、必要なメモリも推論速度も大きく変わる。 Kimi K3やGLM-5.2のような巨大MoEモデルは、オープンウェイトでも個人のMacで実用的に動かせる規模ではない。 「重みが公開されている」と「手元のPCで動かせる」は別の話。

Cursor Grok 4.5 High で作業してたら、着手条件をクリアするために、確認することなくPRを作成しdevelopにマージしちゃった。 他の設定やモデルでも、再現するか、再現しないか、をテストしないと。

チームで開発する際、Cursorのチームプランは良いと思う。 ルールやプラグイン、スキルの配布、更新がチームとして管理できる点は良いと思う。 そして、Cursorのファーストパーティモデルが安いので、気にせずガンガン使える点も良い。

以下を考えると、現在 Kimi K3 を使えるエージェントは、Kimi API を使っていることになるのかな。 🔗 Will Kimi K3 be available for use in Cursor? : r/cursor www.reddit.com/r/cursor/com... 以下のコメントを見ると、「オープンウェイトがでる 7/27 までは Kimi API を経由する必要がある」とのこと。 www.reddit.com/r/cursor/com...

From the cursor community on Reddit

Explore this post and more from the cursor community

reddit.com

コスト面を考慮して、OpenCode CLIで、APIはFireworks経由で、オープンウェイトの色々なモデルを使ってみた感想として… Codex、Cursor、Claude Codeなどの一般的なエージェントを使うほうが良い、という結論になった。 モデルの違いはもちろんのこと、エージェント、システムプロンプト、ツール呼び出し、安定性、バックエンドの内部実装、クライアント毎のベンダーの最適化など、色々と考えると、Cursorなどのエージェントを使うのが良いと感じた。

セールスフォースのERDを整備したくて、sfコマンド使ってエージェントにお願いしたら、簡単に整備できた。 標準オブジェクト、カスタムオブジェクト、フィールド、参照など。 Postgresで近しい状況を作れた。