同じ原稿仕事を agy(Gemini) と Kiro(Claude) にやらせて比べた¶
きっかけ¶
ある説明記事を書く機会があった。
普段から、全体の段取りや進行（オーケストレーション）には Kiro（Claude系のCLI）、速い実装や修正の作業には agy（Google Antigravity CLI / Gemini系）を使い、役割を分けて動かしている。
そこにちょうど、国産LLMの Sarashina が出たという話を見かけた。日本語に特化したモデルということでタイミングも良かったので、この日常の分業体制に組み込んで下書きを書かせてみることにした。
実際に試してみると、Sarashina は日本語の文章としてかなり自然で読みやすかった。ただ、日本語特化だから自然なのはある意味当然で、気になったのは「普段の分業体制に対等な一角として入れるだけの能力があるか？」という点だった。
実際に手を動かして見えてきた差と、分業の現実について記録しておく。
検証の手順¶
今回は次のような流れで進めた。
同じ条件（ターゲット読者、含める要素、制約事項）を agy と Sarashina のそれぞれに渡して下書きを作成。
Kiro で両方のドラフトを読み、構成や不足している要素をレビュー。
そのレビューの指摘を、書いた本人のモデル（agy、Sarashina）に投げ返して修正させる。
自分で書いた原稿も用意し、agy と Kiro の両方にレビューさせて穴を探す。
書く係とレビューする係をあえて別ファミリーのモデルに分けた。同じモデルに自己採点させるより、設計思想の違うモデルに叩かせたほうが盲点が出やすいと考えたためだ。
実装役としての agy (Gemini)¶
agy は Google Antigravity CLI で、中身は Gemini 系（gemini-3.8-flash-high など）。
一番の特徴は、バックグラウンドの非同期ジョブとして走ること。指示を投げるとジョブIDが返ってきて、バックグラウンドで処理が進む。待っている間に別の作業ができるし、終わったら結果を回収すればいい。
job id: implement-xxxxxxxx
model: gemini-3.8-flash-high
result file (written when the job finishes): .../xxxxxxxx.result.md
実際に使って良かったのは、自己検証まで自分で回すところだ。原稿を書いたあと、ビルドが通るかや表示の崩れがないかを自分で確認してから完了を返してくる。「本当に動くのか？」とこちらが確認する前に検証ログを出してくるのは頼もしい。
また、「この5点を直して」と長い複合指示を渡しても、最後まで漏らさず確実に修正してくる。見出し構成を大きく崩して散文にするような指示も破綻なくこなした。
一方で、文章自体は事実と構成がしっかりしている反面、かなり淡白で実務的。読者を惹きつけるような文章の運びを一発で出すタイプではない。また、非同期ジョブで動くため、1行直すような軽い修正でもジョブの起動・完了待ちのオーバーヘッドがあるのは少し気になった。
司令塔としての Kiro (Claude)¶
Kiro は Claude 系のCLIエージェント。今回は自分でも文章を書きつつ、全体の進行役（オーケストレーション）として動かした。
お題の整理と各モデルへのタスク振り分け
上がってきた下書きの評価・レビュー
指摘事項を整理して、どの修正を採用するかの判断
採用した指示を各モデルへ投げ返す
文章を書く能力そのものも、文の繋がりやトーンの整え方という点では一番安定していた。ただ、それ以上に「どう進めるかを判断し、他のモデルの出力を束ねる」進行役として機能していた。
面白かったのは、Kiro が書いた原稿を agy にレビューさせたときだ。Claude が書いた文章に対して、Gemini は「読者への導線（リンク）が1つもない」「前提の説明が抜けていて誤解を招く」といった、文章の表現ではなく構造的な穴をズバズバ突いてきた。同じモデルで自己レビューを回すより、別系統のモデルにチェックさせたほうが明らかに実用的な指摘が出る。
Sarashina の観測結果と分業の現実¶
国産LLMである Sarashina にも同じ条件で下書きを書かせた。1本目に出てきたドラフトは、日本語の言い回しや情景の描写が自然で、人間が書いた文章に近い柔らかさがあった。日本語AIとしての文章力は確かに高い。
ただ、冒頭に書いた通り「日本語特化だから自然」なのは前提であって、それ単体では分業に組み込む理由にはならない。分業に足るかどうかは、「他のモデルが苦手で、Sarashina だけが安く速く確実にこなせる持ち場があるか」で決まる。
実際に試して観測できた事実は次の通りだった。
日本語の自然さや描写力は十分で、最初の下書きはそのまま読める水準だった。
一方で、「この6点を直して全文を書き直して」というような長い複合指示を一度で守りきれなかった。途中で見出し構成が脱落したり、指摘が半分ほどしか反映されなかったりした。
その結果、2回の往復やり取りが発生し、最後は人手で仕上げる必要があった。
分単位のレート制限（RPM）が厳しく、連続でリクエストを投げると待ち時間が発生した。
この結果から見ると、今回の「長文記事のドラフト生成・長文編集」というタスクにおいては、対等な分業の一角としては力不足だった。同じ仕事を agy も Kiro も一発でこなし、指示の遵守でも上回っていたからだ。Sarashina は往復と人手による手直しが増えた分、待ち時間と人の手間を含めたトータルコストが高くついてしまった。
ただし、これは「Sarashina が使えない」という意味ではない。今回の検証は、たまたま長文ライティングという不得意な土俵で走らせた結果であって、能力評価としては一面的だ。
本来の持ち場は、長文の自由生成ではなく、
日英特化の翻訳
高RPMの軽量モデルを活かした大量の処理（要約・分類・タグ付け）
モデレーション（安全性判定）
RAG用途の埋め込みやリランキング
といった、短尺・定型・大量のタスク側にあるはずだ。こうした領域であれば、汎用の agy や Kiro に投げるよりも専用モデルを使う意味が出てくる。
もっとも、「本来の持ち場なら分業に足る」という点も、今回は長文生成しか試していないため現時点では仮説に過ぎない。翻訳や大量分類での精度やコスト優位については、今後別のタスクで実際に検証して確かめる必要がある。
各モデルの比較¶
今回の検証から見えた各モデルの特性と役割を整理しておく。
項目 |
Kiro (Claude系) |
agy (Gemini系) |
Sarashina (国産LLM) |
|---|---|---|---|
役割・持ち場 |
オーケストレーション・進行・評価 |
実装・修正・自己検証 |
（想定）翻訳・分類などの短尺定型タスク |
実行形態 |
対話型の司令塔 |
バックグラウンド非同期ジョブ |
同期API呼び出し |
出力・文章の傾向 |
構成力が高く、文の繋がりが自然 |
淡白で実務的、指示の遵守力が高い |
日本語の言い回しが自然で柔らかい |
今回の検証結果 |
レビュー統合と進行で安定して機能 |
複合修正や構成変更を正確に反映 |
複合指示の取りこぼしがあり、人手修正が発生 |
検証から見えたこと¶
今回の検証で一番手応えがあったのは、書く係とレビュー係を別系統のモデルで分けると、チェックが実質的に機能するという点だった。
同じモデルに自分の出力をレビューさせても、どうしても同じ前提や癖を引きずって甘くなる。Claude が書いた文章を Gemini に叩かせると、文章の良し悪しとは違う角度の欠陥（導線不足や前提の抜け）を淡々と指摘してくる。
また、分業を組むなら各モデルの得手不得手を前提にして持ち場を決める必要がある。
進行と判断、文章の構成統合：Kiro (Claude)
手を動かす実装、自己検証付きの修正：agy (Gemini)
短尺・定型の日本語処理：Sarashina（今後の検証課題）
何でも1つのモデルにやらせようとするのではなく、特性に合わせて投げる先を分けるほうが、待ち時間も人の負担も少なくて済む。
まとめ¶
複数のモデルを動かしてみて、「どのモデルが一番賢いか」という単純な比較よりも、「どの持ち場にどのモデルを置くか」を考えるほうがはるかに実践的だと感じた。 まあ、当たり前のことではある。
Kiro（オーケストレーション）＋ agy（実装）という普段の体制に、国産LLMのような特化型モデルをどう組み込めるかは、長文ライティング以外のタスク（要約や分類、RAGなど）で引き続き試してみたい。