お好きな金額でサポートしていただけると嬉しいです！
(50円〜10,000円[税込]まで)
作成日時：2026年7月19日 20:02
更新日時：2026年7月20日 10:54
LLM
Codex
Sekisyo CLI
OpenAIが2026年7月13日から開催しているグローバルハッカソン「OpenAI Build Week」に参加、7月18日に渋谷で開催されたぬこぬこさん主催のコミュニティハッカソン「Global Build Week Community Event - Tokyo」へ足を運んできました。
イベントでは同じお名前のオータニさんと一緒にWオータニチームを作り、オータニさんアイデアでゲームを作りました！
なかなか時間内に作りこみまで行き届かず悔しかったので笑、家に帰ってから以前から実際の開発現場で感じていた課題感をもとに考えていたアイデアを形にし、提出してみました。
私が作ったのは「Sekisyo CLI」です。AIによって生成されたコードを禁止するのではなく、あくまで開発フローに組み込んだうえで、作業者が変更を説明できる状態に育て、レビュワー負担も減らし、組織的な中長期の教育課題を解消していく、そんなGitのpre-pushフック型のCLIです。
Sekisyo CLI（関所）は、git pushの直前に発火するpre-pushフックとして動作します。pushすると、次のような流れで「口頭試問」が始まります。
git push
│
├─ Codexがコミット済み差分とリポジトリ全体の文脈を分析
├─ 機械的な指摘は一次セルフレビューで処理
├─ GPT-5.6が根拠に基づいた質問を3〜5問出題
├─ 曖昧な回答には追加質問で深掘り
└─ 通過記録をローカルの.git/sekisyo/へ一時保存してpush続行
試問を通過した後はオプションですが、sekisyo prコマンドで設計判断、リスク、検証内容、注意力マップ（差分を機械的変更・定型・必読に分類したもの）、合格したQ&AをPR本文へ書き出せます。レビュアーは差分をまるごと追いかけて、意図を推測したり聞いたりする代わりに、作成者自身の説明を判断材料にすることが叶います。
詳しい説明は興味があればリポジトリを見てもらうとして、ざっくりRemotionで作ってもらったデモ動画を見てもらうのが一番早いかなと（音楽やってた20代ぶりくらいにyoutubeチャンネル作って触ったw）。
AI駆動開発が進むにつれて、コードを書く速度は大きく向上しましたが、一方で人間がコードを理解・判断し、レビューできる速度は同じスピードではなかなか増えません。実際の開発現場で、AIが生成したコードの中身や設計判断を作業者が十分に理解しないまま、レビューへ提出してしまうような場面も増えていると感じていました。
これは、短期的な視点で見れば、レビュアーがコードの正しさだけでなく「なぜこの変更をしたのか」「どこまで理解して出しているのか」などを差分から推測し、読みづらいAIが生成した文章も読んでいかなければいけないという問題ですし、中長期的な視点で見ると、その問題は一生解決せず、むしろ個人個人の、ひいては組織全体としての教育的な役割も担ってきたレビューが、AI時代における新しい大きな組織課題になっていくと考えていました。
漏れなく私自身も、レビューを出す側としても、行う側としても、そういう部分に結構な脳の処理ウエイトを使っている日々です。
既存のAIレビュー周りのサービスとしては、PRの自動レビューやレビュアーの作業を支援したりするものが多くあります。使い方次第ではありますが、コードレビューのskillsなんかもその部類に入る認識です（あとなかなか個人使いとしては導入しやすかったりするものの、組織として、となるとなかなか即導入、はまだまだ進まない会社もあるのが実情な印象です）。
なので、私が求めていたのは、もっと上流でコードを書いた（生成させた）側の理解と学習を促す教育的な仕組みでした。
同時に、AI生成コードを検出して禁止するアプローチには反対です。使わなければそれこそ企業として取り残されていくことに繋がり、大きな経営課題に繋がっていくと思っています。
必要なのはAIを使わない開発を維持することではなく、AIを使う前提を崩さずにその使い方をより良く前進させることだと思います。
そこで、手軽に影響範囲少なく使えて、できるだけ既存の作業フローを変えず、レビューへ進む直前に立ち止まることのできる「関所」を置くという発想に至りました。CLIにしたのはそこが理由です。
一番苦労したのはここです。モデルへ単純に質問生成を依頼すると、「この関数は何をしていますか」のような、コードを読み上げるだけで答えられる質問が生まれがちです。それでは変更のリスクや設計判断を理解しているかが確認できません。そこで、問いを次の4カテゴリに分解し、質問用のタクソノミーとしてプロダクトの仕様に落とし込む流れを組んでもらいました。
また、ポイントとして、何を問うべきか自体を公開可能な仕様として設計したのがポイントです。
タクソノミーは.sekisyo.ymlで自由にカスタマイズすることができるようになっています。
questions:
count: 3
categories:
boundary: true
ripple: true
alternatives: true
failure: true
custom:
- name: accessibility
prompt: >-
For UI changes, ask about keyboard and screen-reader behavior.
paths:
"src/billing/**":
categories:
failure: required
また、良い質問を作るには変更コードの要約だけでは不十分で、「変更していない箇所へ何が波及するか」をLLM側が見つけられることが重要でした。そのためCodex CLIをheadlessで実行し、変更行だけでなく呼び出し元や関連ファイルを含むリポジトリ全体の文脈から差分を分析させています。
ここらへんはまだまだ詰めどころが多いかなと思ってます。
関所という仕組みは、設計を誤ると作業者を監視しAI利用を取り締まるツールになってしまいます。それは作りたいものではありません。Sekisyo CLIでは、次をすべて意図的に許容する思想です。
git push --no-verifyでフックをバイパスすること（Sekisyo CLIの導入がボトルネックになることを防ぐ。回避したければできるように）あくまでSekisyo CLIが判定するのは変更に対して具体的で検証可能な説明になっているかどうかです。中身のある説明をAIに作らせるためには、結局作業者が差分を読み、必要な情報を与え、生成された説明を検証する必要があります。その過程で理解が深まるなら、それも組織としての教育施策の一環になりうると思います。
質問が多すぎると、これもまたSekisyo CLIの導入自体が新しいボトルネックになってしまいます。逆に簡単すぎれば関所として導入する意味なしです。
このバランスは.sekisyo.ymlのstrictnessという1つのキー（light / standard / strict）である程度調整できるようにし（最初にやるのはあまり推奨はしませんが、プロンプトもいじろうと思えばいじれるという設計です）、リスクの高い箇所や人間が判断すべき箇所へ質問を集中させるようにしました。レビューを置き換えるのではなく、レビュー前に理解と注意の向け先を整えるイメージです。
あとは同じく.sekisyo.ymlのcustom欄で好きに観点を追加して、例えばcategoriesのデフォルトの質問をすべてfalseに設定しチームごとのレビュー観点を設定する、といった使い方もできるようにしています。
設計判断はチームの知識として残す価値がありますが、Sekisyo CLIの通過記録を永続的に蓄積していくと、管理コストの増加につながると思いました。ここも両立が難しかったポイントで、最終的にローカルの通行手形は.git/sekisyo/に置く使い捨てとし、長く残す価値のある合格Q&Aや設計判断はPR本文へ要約として記録させるというライフサイクルに落ち着きました。
git notesで恒久保存する案も検討しましたが、お察しの通り追加のpush設定やrebaseとの相性、GitHub UIから見えにくいことを考えて見送りました。サーバーもデータベースも持たない構成にできたのは、この割り切りの副作用で、結構よかったと思っています。
MVPでは、pre-pushフック、Codexによる差分分析、一次セルフレビュー、GPT-5.6による口頭試問と回答判定、注意力マップ、PR本文への書き戻し、質問タクソノミーのカスタマイズまで実装できました。
usageのリミットと締切ドリブンで一気に作ったMVPですが、差分分析、口頭試問、深掘り、pushの続行という一連の体験を、普段使っているgit pushの中へ収められたことにはかなり手応えを感じています。
今後は、Sekisyo CLIを単なるpush前のチェックツールに留めず、柔軟に方針を検討しながら使えるものに育てていけたら楽しいかなと思っています。
利用モデルの柔軟性の拡大、質問ポリシーなど設定のカスタマイズ性追求、パッケージ公開によるbunx sekisyo init一発でのセットアップ、あとは非常に遅い！笑 ので、ほんと改善すべきところは山ほどあります。
地道にちょこちょこ触る感じの温度感で考えていますが、AI駆動開発の課題が今後の組織としての大きな課題になっていく、といった部分に共感を持ってもらえたら、ぜひ一度触ってみていただけると嬉しいです。IssueやPRもお待ちしています！
Build Weekのようなイベントは、温めていたアイデアを世に出す後押しとして最高でした！
ぬこぬこさんのハッカソン開催によって、他の参加者の作品や熱量に触れられたのも、ほんとに大きな刺激になりました。周りにすごい人たくさんいすぎて、いつもビビりますが笑
きっかけをいただけたことに、感謝しています。
めっちゃ楽しかった！！！