TL;DR: Qiitaの「ai& Inference」テーマ賞コンテストに3記事投稿し、いずれも無冠に終わりました。「N=1の限界を正直に書きすぎたのでは」と疑い、5つの独立したAI(ClaudeCode/Fable・Codex/Sol・Gemini・ai&のKimi・SakuraのKimi)に、受賞13記事と自分たちの3記事を比較分析させたところ、誠実さ自体は無罪でした。同じ開示スタイルで受賞した記事が複数あったからです。5AIが揃って指摘した本当の正体は、記事の主題そのものにありました。受賞記事はモデルや設定を「外部の課題を解く道具」として扱っていましたが、自分たちの3記事は、モデルや設定そのものを検証する社内実験レポートになっていたのです。この診断を、記事の構造に関する恒久的なルールに落とし込んだところまでをまとめます。
結論: 全敗の正体は、誠実さではなく「社内実験レポート」だった
「ai& Inference」というOpenAI/Claude互換APIを国内で提供するプラットフォームのQiitaテーマ賞コンテストに、3記事を投稿しました。7つのオープンウェイトモデルに同じ記事を独立に書かせ、別のAI審査員に採点させた実験。生成設定のデフォルト値を検証した実務ノート。7モデルのコードレビュー性能を実際のバグ検出数で比較した記事。いずれも、N=1であることや測定していない変数を明記した、誠実な記事のつもりでした。結果は3記事とも無冠でした。
最初に疑ったのは、「限界を正直に書きすぎたせいで、審査員に弱い記事だと見えたのではないか」という仮説でした。しかし、5部門・11名の著者による受賞13記事と自分たちの3記事を、5つの独立したAIに見せて分析させたところ、この仮説は外れました。受賞13記事の中には、自分たちと同じように「この最適化はほとんど意味がなかった」「2品しか検証していない」と正直に書いた上で受賞した記事が複数あったからです。誠実さと受賞は両立していました。
では何が問題だったのか。5AIが独立に、そして揃って指摘したのは、もっと根本的な話でした。受賞13記事は、モデルや設定を「読者が抱える具体的な課題を解決するための道具」として扱っていました。会議の議事録作成に追われている、メールが届かない、正規表現のケースが漏れる——そうした外部の困りごとを解決するために、たまたまそのモデルや設定を使った、という構成です。
対して自分たちの3記事は、モデルや設定そのものが検証対象でした。「7モデルにスコアのばらつきが出るか」「3つの設定にどんな挙動差があるか」——これは読者の困りごとを解決する記事ではなく、自分たちが知りたかったことを確かめた社内実験の報告書でした。読者に届ける記事のつもりで、実際には自分たち向けのレポートを書いていた、というのが5AIの診断です。
Before/After: 何が変わったか
| 項目 | 受賞13記事に共通する型 | 自分たちの3記事 |
|---|---|---|
| 主題 | モデルや設定は、読者の外部課題を解決する道具として扱われる | モデルや設定そのものが検証対象になっている(社内実験レポート) |
| 冒頭 | 具体的な痛み(壊れた運用・食い違った結果)から始まる | 方法論・実験設計から始まる |
| 正解の所在 | 読者が自分で確認できる外部の結果(印字されたカロリー表示、実際の配送率等) | AIが別のAIの出力を判定するなど、検証が内部で閉じている |
| 詰まった点 | 名前付き・番号付きの独立セクション(「3つの移行失敗」「4つの落とし穴」等) | 末尾のLimitationsに埋もれている |
| 締め方 | 状況別の判断表・行動指針 | 読者への問いかけ |
| 誠実さ・N=1開示 | 複数の受賞記事が同じ開示スタイルを採用 | 同じ開示スタイルだが無冠 |
誠実さの行だけが両者で一致していることに注目してください。ここが同じだったからこそ、5AIの診断は「誠実さは原因ではない」という結論に自然と行き着き、代わりに主題そのものの違いにたどり着きました。
詰まった点: 根本原因は1つ、症状は3つ
根本原因: 主題が「外部の課題を解く道具」ではなく「モデル・設定そのもの」だった
受賞13記事は、モデルや設定を主役にしていませんでした。主役は常に、読者が想像できる具体的な困りごとで、モデルや設定はその困りごとを解決するために使われた道具の1つに過ぎません。
自分たちの3記事は逆でした。モデルや設定そのものが主役で、「このモデルはどう振る舞うか」を確かめることが記事の目的になっていました。技術検証としては誠実で正確でも、読者が抱える外部の課題とは接続されていない、社内向けの実験報告書の構造です。この主題のズレが、次の3つの症状として現れていました。
症状1: 冒頭が方法論から始まり、痛みから始まらない
社内実験レポートは、「何を検証したか」から始まるのが自然です。実際、自分たちの3記事は「7モデルに同じ記事を書かせてスコアのばらつきを見た」「3つの生成設定を検証した」のように、検証対象そのものから書き始めていました。
受賞13記事は逆に、「公式ドキュメントの主張を検証したら実測値が違った」「送信済みのはずのメールが届かなかった」のように、読者が想像できる具体的な事故や違和感から始まっていました。読者の課題が先にあり、検証はその課題を解くための手段として後から出てきます。
症状2: 検証が内部で閉じていて、読者が自分で正解を確認できない
自分たちの3記事のうち1本は、複数のAIモデルに書かせた文章を、別のAI審査員に採点させる構成でした。技術的には妥当な実験ですが、読者からすると「AIがAIを判定した結果」を信じるしかなく、自分で正解を確かめる手段がありません。
受賞13記事の直接の競合(カロリー推定の記事)は、AIにカロリーを推定させ、実際に印字されたカロリー表示と突き合わせていました。読者は写真とラベルを見れば、AIの答えが合っていたかどうかを自分で判断できます。検証が外部の現実に対して開かれているか、AI同士の判定で閉じているか——ここが分かれ目でした。
症状3: 判断表でなく問いかけで締めていた
受賞記事の締めは、「状況Aならこちら、状況Bならこちら」という条件付きの判断表や行動指針がほとんどでした。読者が抱える課題は最初から明確なので、締めもその課題への回答になります。
自分たちの3記事は、末尾に読者への問いかけを置いていました。誠実で謙虚な締め方のつもりでしたが、そもそも記事の主題が読者の課題ではなく自分たちの検証だったため、読者に返せる具体的な回答が用意できていなかった——というのが実態に近いようです。
実際に変えたこと
この診断を踏まえて、記事の構造に関する恒久的なルールを新設しました。最も大きな変更は、記事の主題そのものの据え方です。
- 記事の主題は、モデルや設定そのものではなく、読者が抱える具体的な外部課題を解決する道具として据える
- 検証は、読者が自分で正解を確認できる外部の現実に対して開く(AI同士の判定だけで閉じさせない)
- タイトルは投稿先コミュニティの言語で書き、具体的な数字と緊張感を1つずつ含める
- 冒頭は方法論の説明ではなく、具体的な事故や痛みから始める
- 詰まった点・誤算は、末尾のLimitationsに埋もれさせず、名前付き・番号付きの独立セクションにする
- 締めは読者への問いかけではなく、状況別の判断表にする
既存の別ルール——内省的な問いかけで締める、足場を隠すという有料読者向けエッセイの書き方——を置き換えるものではありません。コンテスト投稿やQiita・Medium・Zenn向けの無料公開記事という媒体に限定した、別建てのルールとして運用しています。誠実さ・N=1の開示という編集方針そのものは変えていません。変えたのは、その誠実さを何に向けて発揮するかという、記事の主題の据え方だけです。
状況別の使い分け
| 状況 | 推奨対応 |
|---|---|
| 複数モデル・複数設定を横並びで検証する記事を書く | モデルや設定そのものを主題にせず、読者が抱える具体的な外部課題(壊れた運用・食い違った結果)を解決する道具として位置づける |
| AI同士の判定・比較が検証の中心になりそうな記事を書く | 読者が自分で正解を確認できる外部の現実(公開情報・印字された数値・実際の挙動)を検証対象に含める |
| Qiita・Medium・Zenn等、コミュニティ投票やコンテスト審査がある無料公開記事を書く | タイトルは投稿先の言語で、冒頭は具体的な痛みから、締めは判断表で書く |
| Substack・note.com等、有料読者向けの長文エッセイを書く | 従来通り、内省的な問いかけで締め、足場を隠す書き方を維持する |
| 検証・比較の記事で、N=1や測定していない変数がある | 開示自体は省略しない。ただし開示を外に投げる問いにせず、「この条件では」という形で判断表の枠内に収める |
| 詰まった点や失敗が複数ある | 末尾にまとめず、名前付き・番号付きの独立セクションとして本文の主要な構成要素にする |
参考リンク
- イベントページ: OpenAI・Claude APIと互換性あり！国内AIモデル推論プラットフォーム「ai& Inference」を使ってみよう
- 受賞者一覧: Qiita Tech Festa 2026 Award
今回無冠に終わった、私たちが投稿した3記事です。