Rustに最適なAIコーディングアシスタントは？

2026-08-27

所有権、ライフタイム、Cargo crateのエラーをデバッグするAI Rustコーディングアシスタントを使う開発者

AI Rustアシスタントは、所有権の安全性、crateの新しさ、イディオマティックな出力でどのように異なるのか？

2026年のRustで通用するAIアシスタントは、所有権をcloneで回避するのではなく、所有権について推論し、非推奨のAPIではなく最新のcrate APIを使い、Clippyが受け入れるコードを出力するものです。Rust Coding Assistantは、会話を中心としたシニアパートナーとして、その基準を軸に構築されています。CursorとGitHub Copilotは、rust-analyzerと連携したIDE内では依然として強力です。一方、Claude CodeとAiderは、ターミナル中心でGitを多用するワークフローに適しています。

同じAxum HTTPサーバーを使って7つのAIコーディングツールを独立検証した結果、その違いは明確でした。IDEエージェントは高速に雛形を作成できますがcrateのバージョンを創作することがあり、Copilotは行を素早く補完できますがファイル間で一貫性が崩れ、CLIエージェントはライフタイムをうまく説明できる一方、API全体をmain.rsに詰め込むことがよくあります（Shuttleによる2025年の比較検証）。コミュニティの記事も同様の結論に達しています。多くの汎用ツールはライフタイムや古いcrateを幻覚します。

役に立つRust支援と、一般的なオートコンプリートを分ける主な要素は次のとおりです。

✅ 所有権への忠実度 — .clone()で借用チェッカーを黙らせるのではなく、データフローを再構成する ✅ crateの新しさ — Axum、Tokio、serde、sqlxを、2つ前のメジャーバージョン時ではなく、現在の仕様に沿って使う ✅ イディオマティックなデフォルト — Resultと?を使い、本番パスで.unwrap()を使わず、crateの種類に応じてthiserror／anyhowを使い分ける ✅ 診断の質 — rustcが最後に出力した行ではなく、実際のライフタイムの衝突まで借用エラーを追跡する ✅ ワークフローへの適合性 — エディター内の補完か、チームメイトのように説明する専門家か

これらのツールを有意義に比較するには、どのインターフェースが最も「エージェントらしい」かではなく、この5つの側面で評価するとよいでしょう。

他の言語と比べて、RustでのAI支援はなぜ特にリスクが高いのか？

Rustは、ガベージコレクターを持ち型システムがより緩やかな言語よりも、もっともらしいものの間違っているコードを厳しく拒みます。そのため、JavaScriptでは「たいてい問題ない」アシスタントでも、Rustではコンパイルサイクル全体を無駄にする可能性があります。借用チェッカー、トレイトの一貫性、エディションとMSRVの制約により、小さな幻覚がハードエラーになります。GitHub自身も、Copilotの提案品質は言語に存在する公開トレーニングデータの量によって変わると説明しており、RustはそのコーパスにおいてJavaScriptより薄い言語です。

2025年のRustの現状調査には7,156件の回答が寄せられ、日々の最も難しい問題にはほとんど変化がないことが分かりました。特に遅いコンパイルやディスク使用量などのリソース使用量が、依然として上位にあります。その環境では、間違ったAI出力は高くつきます。存在しないfeature flagや誤ったSend境界を1つ生成するたびに、別のcargo checkが必要になるからです。同じ調査では、公式ドキュメントが依然として優先される正典リファレンスである一方、一部の質問をLLMツールに移す人々もいることが確認されています。

初心者はリスクをさらに高めます。JetBrainsの報告によれば、2025年には回答者の30%が1か月未満前にRustを使い始めていました。この層は、cloneが多く.unwrap()だらけのスニペットを「Rustの書き方」だと受け入れてしまうでしょう。Stack Overflowの2025年の結果でも、開発者はAIを使う意欲はあるものの、信頼することには慎重であることが示されています。これは、Rustaceanが生成コードを「役に立つ下書きであって、絶対的な答えではない」と扱う姿勢と一致します。

だからこそ、Rust専用アシスタントは汎用コーディングチャットに化粧を施しただけのものではありません。生成されたシステムコードを高コストにする失敗パターンを防ぐフィルターなのです。

AI Rustコーディングアシスタントを評価する際、どの基準を使うべきか？

Rustアシスタントは、所有権への忠実度、crate APIの新しさ、イディオマティックなデフォルト、診断の深さ、そしてIDE・ターミナル・会話型ワークフローのどれに適合するかで評価すべきです。自信満々にtokio::mainのテンプレートを貼り付けるかどうかで評価してはいけません。2026年には、ほとんどのツールがRustらしく見えるものを出力できます。この5つの側面が、実用的な評価表になります。

所有権への忠実度。 アシスタントがエイリアス、スコープ、データレイアウトを変更するのか、それとも最初の反射的な対応として.clone()、Rc<RefCell<T>>、'staticに頼るのかが重要です。シニアレベルのRust開発では、これらは最後の手段です。

crateの新しさ。 Axumのextractor、hyper 1.xのbody型、sqlxのマクロ、clapのderive APIは変化します。最新のドキュメントを確認しないアシスタントは、2023年にはコンパイルできても2026年には失敗するコードを生成します。ShuttleのAxumテストでは、能力の高いIDEエージェントでさえ存在しないcrateバージョンを生成することが確認されました。

イディオマティックなデフォルト。 本番用Rustでは、?を使ったResult、構造化エラー、残されたprintln!ではなくtracing、そして文書化されたunsafeを使います。ライブラリのパスで.unwrap()を出力するアシスタントは、公開可能なcrateではなくスクリーンショット向けに最適化しています。

診断の深さ。 rustcのエラーチェーンは症状を示します。役に立つ支援は、根本原因を特定します。たとえば値が早く破棄された、.awaitをまたいでMutexGuardを保持している、あるいはトレイト境界によってfutureが!Sendになった、といった原因です。

ワークフローへの適合性。 エディター内のrust-analyzerは、入力中に型を検出します。会話型の専門家は、エディション、Tokioのfeature、エラーcrateを記憶します。CLIエージェントは複数ファイルにパッチを適用し、cargo testを実行します。5つすべてで勝つ製品はないため、「最適な」答えは状況によって異なります。

二次的な確認項目も重要です。エディションとMSRVへの対応、テスト生成（#[cfg(test)]、proptest、criterion）、そしてツールがCargoを実行できるのか、それとも実行するコードを書くだけなのかを確認しましょう。

Cursor、GitHub Copilot、Claude Code、Aiderは実際のRustプロジェクトにどう対応するのか？

CursorとCopilotは、rust-analyzerと連携するIDEコンパニオンとして最も強力です。Claude CodeとAiderは、ファイルを計画してパッチを適用するターミナルエージェントとして優れています。JenovaのRust Coding Assistantは、スニペット単位で正確かつイディオマティックなRustを書き、実際の障害が所有権にある場合にはそれを説明する言語専門家として最も力を発揮します。ShuttleによるAxum APIの横並びテストは、同じRustタスクでこれらのワークフローを比較した、最も具体的な公開比較です（完全な記事）。

機能／側面	Cursor	Jenova Rust Coding Assistant	GitHub Copilot	Claude Code	Aider
所有権／借用チェッカーの支援	LSPの診断が表示されていると強力。ただし品質はモデルによって異なる	cloneを最初に使う修正ではなく、所有権のメンタルモデルを中心に設計	ローカルなヒントは高速。関数全体の再設計は弱い	Shuttleのテストでライフタイムの説明が強力	視覚的な借用フィードバックではなく`cargo check`に依存
crate APIの新しさ	雛形作成は高速。crateバージョンを幻覚することがある	crateドキュメントとバージョン依存APIを優先して調査	公開リポジトリで学習。データの少ない言語では提案が弱くなる	同じテストでAxum／asyncの処理が正確	複数ファイルを編集。検証はコンパイル主導
複数ファイルの雛形作成	モデル、ルート、`main`の同期に非常に優れる	対象を絞ったパッチに強い。リポジトリ内のパッチ実行は行わない	Shuttleのテストではファイル間の型の一貫性が弱い	計画してからファイルを書き込む。冗長になることがある	ファイル間でアトミックなGitコミット編集
IDE／rust-analyzerループ	ネイティブ（VS Codeフォーク）	なし — インラインLSPではなく会話とスニペット	VS Code、JetBrains、Neovimなどでネイティブ対応	ターミナル。コンパイルして検証	ターミナル／Git中心
料金（2026年時点）	Hobbyは無料。Individualは月額$20。Teamsはユーザーあたり月額$40（Cursorの料金）	使用量に制限のある無料プラン。Plusは月額$20（使用量30倍）	上限付き無料プラン。Pro+は月額$39。Maxは月額$100（Copilotのプラン）	Proは月額$20でClaude Codeを含む。Max 5xは$100。Max 20xは$200（プランの内訳）	オープンソース。接続するモデルプロバイダーに支払う
最適な用途	エディター内でのRustの雛形作成とリファクタリング	所有権のデバッグ、crateに正確なコード生成、学習と出荷の適応的な支援	入力中の行単位の補完	構築しながら説明するターミナルエージェント	自動コミットを使うGitネイティブなペアプログラミング

Cursor

CursorはAIネイティブエディターです。ShuttleのAxum試験では、Cargoプロジェクトを作成し、CRUDハンドラーを埋め、複数ファイルを編集してモデルとルートの整合性を維持しました。コンパイラーエラー後のインラインフォローアップは明確な強みでした。同じテストでは再プロンプトが必要になり、最終的には存在しないcrateバージョンも確認されました。SemVerを契約として扱うCargoエコシステムでは、これは痛い失敗です。Individualプランは月額$20からで、無料のHobbyプランとユーザーあたり月額$40のTeamsがあります（Cursor）。ヘッドレスサーバーを使い、GUIを一切望まない場合には適していません。

GitHub Copilot

Copilotは、行内ペアプログラマーの標準的な選択肢であり続けています。VS Code、JetBrains（RustユーザーフォーラムでRustRoverとともに語られるワークフローを含む）、Neovim、そしてGitHub独自のUIに対応しています。Shuttleの検証では、スニペット生成が最も高速で、コンパイラーエラーの説明も十分でしたが、ファイル間で型の整合性を維持することや、API全体を一度に生成することは苦手でした。GitHubは、Copilotユーザーがコードを書く際に最大55%生産性が向上すると報告しています。この数値はベンダーによる報告であり、Rustに特化したものではありません。無料アカウントには上限があります（公開されている無料プランでは補完2,000回、チャットリクエスト50回）。2026年時点の有料個人向けプランには、月額$39のPro+と月額$100のMaxがあります（GitHubのプラン一覧）。請求体系は引き続きクレジット中心へ移行しています。

Claude Code

Claude CodeはAnthropicのターミナルコーディングエージェントで、Proプランに含まれています（Claudeの料金）。Axumの比較検証では、正確なasyncコードを生成し、ライフタイムとエラーメッセージの説明において最も優れていました。その代わり、反復は遅く、コメントが多い出力になりました。この特性は、無言の補完ではなく、教師とジェネレーターを兼ねたツールを求める開発者に向いています。2026年の公開まとめでは、Proは月額$20、Max 5xは$100、Max 20xは$200とされています（Superblocks）。他のCLIエージェントと同様、検証にはrust-analyzerではなくCargoを使うため、コンパイルサイクルというコストがかかります。

Aider

Aiderは、オープンソースでGitを認識するペアプログラマーです。crateの雛形を作成し、複数ファイルを編集し、各ステップでコミットメッセージを書きます。Shuttleは、このGitワークフローを独自性があり本番向きだと評価しました。代償は他のターミナルツールと同じです。ネストしたライフタイムに対する視覚的な支援が少なく、自分でcargo checkを実行することに慣れている必要があります。料金は持ち込むモデル次第で、Aider自体はホスト型IDEではありません。

Jenova Rust Coding Assistant

Jenovaのエージェントはエディタープラグインではありません。シニアRustチームメイトのように振る舞います。つまり、本番向けのデフォルト（Result、ライブラリパスでunwrapを使わない、rustfmtに沿ったコード）、エディションへの対応（安全なデフォルトとして2021を使い、新しい構文にはMSRVに関する注意を付ける）、そして修正を依頼された関数だけを返す習慣があります。最後の点は重要です。汎用エージェントはmain.rs全体を再生成し、use行や#[derive]属性を黙って削除することがよくあります。

制限も同じく具体的です。コンパイル、テスト実行、ディスク上のdiff適用はできません。rust-analyzerのセッションもないため、入力中に不要なmutへ下線を引くことはありません。周辺作業としてSQL、Dockerfile、CI YAMLは書けますが、完全なPythonサービスにはPython Coding Assistantが適しています。また、C++との相互運用が多いモジュールはC++ Coding Assistantに依頼する方がよいでしょう。プロジェクトの永続メモリ（エディション、Tokioのfeature、エラーcrate）がその補償になります。次のセッションでも、空のチャットではなく、Axum 0.8とsqlxを使っていることを把握しています。

AIアシスタントは借用チェッカーとライフタイムのエラーをどのように診断すべきか？

役に立つアシスタントは、コンパイラーのエラーチェーンをたどり、長く生きすぎている値や所有者より長く続く借用を特定して、その領域だけを修正します。rustcが静かになるまで'static、.clone()、Arc<Mutex<T>>をばらまくことはしません。この違いが、所有権モデルを学ぶことと、型チェックは通るものの技術的負債を蓄積することの分かれ目です。

生成Rustにおける一般的な失敗パターンは、現在ではよく知られています。汎用ツールはライフタイムや古いcrate APIを創作します。rust-analyzer上で動くIDEエージェントは、この一部をリアルタイムで検出できます。そのためShuttleは、LSPに対応したツールが所有権のミスによるコンパイルの往復を減らすと主張しています（IDEとターミナルの比較）。一方、CLIエージェントはパッチを出力してcargo buildの結果を待ちます。モデルの最初の反応がcloneではなく再構成であるなら、どちらも機能します。

JenovaのRust Coding Assistantに借用エラーを貼り付ける場合、想定されるループは絞り込まれています。

crate全体ではなく、ファイル名と関数名を伝える。
最後の1行だけでなく、rustcのエラーチェーンを貼り付ける。
制約を明示する（追加のアロケーション不可、Sendを維持する必要がある、公開シグネチャを変更できないなど）。
crateの書き直しではなく、その関数の差し替え可能な実装を求める。

「エディション2021、Tokioのcurrent-thread。src/pipeline.rsのprocess_batchがE0502で失敗します。HashMapをcloneしないでください。関数シグネチャは維持してください。関数本体と、それに必要なuse行だけを返してください。」

CursorまたはCopilot Chatでは、rust-analyzerの診断を表示したままにして、根本となる借用を説明してからパッチを適用するようチャットに依頼します。Claude Codeでは、Shuttleのテスターはエージェントに構築過程を説明させることで、よりよいライフタイム学習ができました。これは学習には役立ちますが、&mut selfとspawnされたタスクが共存できない理由をすでに理解している場合は遅くなります。

評価表では、async特有の落とし穴にも注意してください。async fn内のstd::sync::Mutex、.awaitをまたいで保持されるMutexGuard（Tokioのワークスティーリングランタイムではfutureが!Sendになる）、そしてリクエストハンドラー内のthread::sleepです。lock()に対するunwrapでこれらを「修正」するアシスタントは、問題を解決していません。

Rustでは、汎用的なコード補完よりcrateエコシステムへの習熟が重要なのはなぜか？

本番用Rustの大部分は、TokioとAxumとserdeとsqlxの組み合わせだからです。言語構文しか知らない補完機能では、昨年のextractorや、誤ったhyperのbodyトレイトを出力してしまいます。Cargoのfeature flag、MSRV、0.xバージョンの破壊的変更があるため、「Rustらしく見える」ことは弱い成功指標です。

Shuttleのテスターは、バージョンを固定せずにAxum、Tokio、serde、uuidを標準化し、そのうえでツールが構造と依存関係について異なる判断をする様子を観察しました（方法論）。Cursorによるバージョンの幻覚は分かりやすい失敗です。より静かな失敗としては、Axumのハンドラーでstd::sync::Mutexを使う、Axumプロジェクトでrocketのパターンを使う、あるいはリポジトリがすでにsqlxのコンパイル時チェック付きクエリに統一されているのにDieselのDSLを使う、といった例があります。

言語専門のエージェントは、ドメインごとに現在のイディオムをデフォルトにするべきです。AxumではTower middleware、ライブラリではthiserror、バイナリではanyhow、場当たり的なlog設定ではなくtracing、builder APIが必要でない限りclapのderive API、そしてcrateの方向性がそうであれば古いTLSスタックよりrustlsを使います。また、crateが変更されたばかりなら推測を拒むべきです。hyper 1.0のbodyトレイトは、チュートリアルを無効にする変更の典型例です。

この習熟度が、リポジトリが複数の言語にまたがったときに関連する専門家も重要になる理由です。PyO3バインディングは、Pythonに精通したパートナーとレビューする方が簡単です。GoのサイドカーサービスはGo Coding Assistantに任せる仕事であり、Rustエージェントがgoroutineを即興で作るべきではありません。逆方向のFFI（cxx、cbindgen）でも、unsafeの文書化はRust側が、イディオマティックな型は非Rust側が担当する必要があります。

Rust向けAIコードレビューツールに関するGraphiteのまとめも、別の角度から同じギャップを示しています。モデルがこのcrateグラフにおける「イディオマティック」の意味を知らなければ、生成もレビューも失敗します。補完の速さでは、その不足を補えません。

AIコーディングセッションから、コンパイル可能でイディオマティックなRustを得るには？

AIセッションからコンパイル可能なRustを得るには、最初に契約を明確にします。エディション、MSRV、ランタイム、エラーcrate、「この関数だけをパッチする」という条件を決めたうえで、重要な変更のたびにローカルでコンパイルします。この比較に登場するどのツールもcargo testの代わりにはなりません。GitHubの生産性に関する主張でさえ、人間がコードを出荷することを前提にしています（Copilot）。

JenovaのRust Coding Assistantに対する簡潔な依頼は、次のようになります。

エージェントを開き、スタックを1つのブロックで伝える（エディション、rustcのバージョン、Axum／Tokio／serde／sqlx、バイナリかライブラリか）。
新しいファイルが必要な場合を除き、ワークスペース全体ではなく、失敗している関数またはrustcの出力を貼り付ける。
譲れない条件を明示する。ライブラリパスでunwrapを使わない、余分なcloneを使わない、公開APIを変更しない、など。
自分のマシンでcargo clippyとcargo testを実行し、「動きません」という曖昧な説明ではなく、次の診断結果を返す。

「ライブラリcrate、エディション2021、MSRV 1.75。Tokio上でthiserrorとsqlx 0.8を使っています。コンパイル時にチェックされるクエリを使ってlist_ordersを追加してください。Dieselには切り替えないでください。src/orders.rsと、有効化するCargo.tomlのfeatureだけを示してください。」

Cursorについて、Shuttle自身のベストプラクティスは、リポジトリをプロダクトとして扱うことです。ルールファイルを書き、API規約を明示し、エージェントが埋もれたREADMEを守ると想定しないでください（ガードレールのセクション）。また、CLIツールは一部のIDEエージェントよりも一貫してルールファイルを尊重する傾向がある一方、サブスクリプションのトークンをより速く消費すると指摘しています。AnthropicのMaxプランは、その支出を予測しやすくする目的もあります（ClaudeのMax利用量ティア）。

テストの規律も同じくらい重要です。振る舞いが分かる名前のテストを持つ#[cfg(test)]モジュール、panicが契約である場合に限った#[should_panic]、そしてパーサーやcodecが対象の場合のプロパティテストを依頼しましょう。アシスタントがテストがない理由を説明できないなら、そのコードはスケッチにすぎません。

Jenovaに期待すべきでないこともあります。スケジュールされたcargo auditの実行、breaking releaseを監視するcrates.ioの監視、CIへのSSH接続などです。これらは範囲外です。また、入力中にrust-analyzerを置き換えることも期待しないでください。このループではCopilotとCursorが依然として勝っています。

システムプログラミングの専門家は、AI生成Rustについて何と言っているのか？

AIをオートコンプリートのおもちゃではなく、コンパイラーを理解するパートナーとして扱う実務者は、使えるRustを得ています。一方、レビューしていない出力を貼り付けるチームは、clone、古いcrate、余分なコンパイルサイクルという形で代償を払います。この見方は、公式調査で確認されたLLMへの移行と、ShuttleのAxum比較検証の両方と一致します。

「汎用コーディングモデルがRustで失敗する場所は、予測可能な3つです。存在しないcrate featureを創作する、借用エラーをcloneで回避する、そしてasync関数内でstd::sync::Mutexによりブロックする。これらは単なるスタイル上の細かな問題ではありません。デッドロックするまで型チェックを通る、あるいは最初から型チェックを通らない本番障害です。つまり、2025年の調査ですでにコミュニティ最大の課題とされているコンパイル予算を消費することになります。」

「単一のAxumサービスでの比較検証を見ると、製品の違いは明確です。IDEエージェントは高速に雛形を作成し、その後バージョンを幻覚します。Copilotは次の行には非常に優れていますが、次のファイルでは不安定です。CLIエージェントはライフタイムを説明した後、ハンドラー、モデル、ルーティングを1つのmain.rsに残します。不足しているのは、エディション、MSRV、エラーcrateの選択、「パッチした関数だけを返す」という条件を第一級の状態として扱い、rustcを判定役にするアシスタントです。」

「言語専用のエージェントも、rust-analyzer、cargo clippy、unsafeに対するMiriの代わりにはなりません。ワークフローの80%がファイルへの入力なら、CursorまたはCopilotを使い続けてください。ワークフローが『このライフタイムエラーは私を欺いている』または『現在のAxum extractorのパターンは何か』なら、プロジェクトメモリを持つ専門家チャットの方が高い効果を発揮します。予算が許すなら両方を使いましょう。ただし、1つのインターフェースが両方の仕事を担えるとは考えないでください。」

— Jenova Product Team、システム言語向けAIエージェントの設計

学習を目的としたQwenベースのアシスタントであるCNCFのRustCoder実験も、汎用オートコンプリートが型システムを吸収するのを待つのではなく、エコシステムがRust向けにモデルを専門化していることを示す別のデータポイントです。エージェント機能を備えたエディターも公式調査で増加しており、VS CodeとIntelliJのシェアを一部侵食しています。だからこそ、上記の評価基準は重要になります。ループに参加するエージェントは増えますが、unsafeについて正直なエージェントは一部にすぎません。

AIネイティブIDEより、言語専門のRustエージェントが適しているのはどんな場合か？

ボトルネックが意味論、つまり所有権、crateの選択、asyncの境界、エラー型にある場合は、言語専門のRustエージェントが適しています。一方、ボトルネックがキーストローク、ディスク上の複数ファイルのリファクタリング、配置されたrust-analyzerの診断である場合は、AIネイティブIDEが適しています。多くの現役Rust開発者は最終的に両方を求めます。これらの仕事は1つの製品に統合できないからです。

次のような場合は、専門家との会話（JenovaのRust Coding Assistant）を選びましょう。

E0502／E0597クラスのエラーをデバッグしており、cloneではなくデータフローを変更する必要がある
crateを追加する際、どのfeatureをCargo.tomlに記述すべきかが重要
デモ用のmainではなく、ライブラリ品質のエラー、ドキュメント、テストを書いている
futureが!Sendになる理由を学びたいが、理由のないArcの定型句は受け入れたくない
READMEを毎回貼り直さず、エディション、MSRV、スタックをセッション間で維持したい

次のような場合はCursorまたはCopilotを選びましょう。

大規模なワークスペースで、毎分rename／refactorとLSPが必要
すでに設計したファイルのボイラープレートを埋めている
コピー＆ペーストなしで、Git管理下のファイルに直接パッチを適用したい

次のような場合はClaude CodeまたはAiderを選びましょう。

ターミナル、作業単位としてのGitコミット、そして真実を判断するcargo testを好む
サービスの雛形を作成し、計画され説明付きの処理を待てる

コストはインターフェースに応じて変わります。CursorのIndividualプランは、使用量超過分を除いて月額$20です（[公式料金](https://cursor.com/pricing)）。IDEエージェントを多用すると席の料金を大幅に超える可能性があり、Shuttleは長期プロジェクトにおける現実的な予算問題として指摘しています。Copilotの無料プランはインライン品質を評価するには十分で、月額$100のMaxは継続的なエージェントワークフローを対象としています（プラン）。Claude Codeの支出はProまたはMaxに基づきます（Anthropic）。Jenovaの無料プランでは1日の使用量に制限がありますが、月額$20のPlusではその上限が30倍になります。これは会話型の使用であり、常時接続されたエディター内補完ではありません。

同じ週にC++やGoも必要だと分かっているなら、1つのモデルに3つの型システムを装わせるのではなく、それぞれの言語パートナーを分けてください。適切な分担は、意図的にシンプルです。バッファーにはrust-analyzer、真実のためにはCargo、そしてオートコンプリートでは見えない判断にはRustに精通したエージェントを使います。