日本の開発プロセスを変える。退屈しないワクワクするAIエージェント「ONIAGENT」を実現
はじめに
ITエンジニアのたくわんです。
26歳、(元)学生です。
前回の記事では、GitHub Actions と OpenAI API を使って、AI エージェントがコーディング、レビュー、修正、単体テスト、レポート作成、Issue 起票、commit / push まで行うワークフローを作りました。
ざっくり言うと、
- GitHub Issue に要件を書く
- GitHub Actions で AI ワークフローを起動する
- AI が branch に成果物を生成する
- レビューやテストに失敗したら修正ループを回す
- 試験結果を Markdown / HTML レポートとして残す
- 最後は人間が Pull Request を見て判断する
という構成です。
前回記事はこちらです。
そしてここから、いよいよ次の段階に進めます。
その名も、
ONIAGENT
オニエージェント。
元ネタは、あの「ジュースがない時に親が出す、地味でワクワクしない飲み物」の常識を変えたいと豪語した例のあの人の、例のアレです。
あの熱量を見たときに思いました。
こっちは日本の麦茶ではなく、日本の開発プロセスを変えたい。
「退屈な飲み物」を変えようとした例のアレに対抗して、
こちらは 退屈な開発工程 を変えます。
設計書。
レビュー表。
単体試験。
エビデンス。
障害票。
再試験。
進捗報告。
うわあ……これは JTC 開発ですね……。
なんだこれは……たまげたなあ。
でも、ここを変えないと日本の開発はいつまでも変わらない。
ONIAGENT は、
「日本の開発プロセスを、退屈な作業の山から、ワクワクするAIエージェントワークフローに変える」
ことを目指す個人 PoC プロジェクトです。
つまり、退屈な工程に対して、
ほならね、自分が自動化してみろって話でしょ？
と言われた気がしたので、自分がやります。
設計書の海、試験証跡の山、レビュー指摘の沼。
これを前にして「いやー、きついっす」と言うだけでは、何も変わらない。
だったら AI エージェントで、
- 要件を読ませる
- 設計させる
- 製造させる
- 試験させる
- ガバを検出させる
- 証跡を残させる
ここまでやって、JTC の開発工程に
いいよ！こいよ！
と言える状態を作りたい。
やりますねぇ！
注意書き
変態クソITエンジニアに調教された半導体の使い所さん！？
何してるんですか、やめてくださいよほんと！(淫夢要素を含みます)
※この記事は私が調教した汚れ好きの土方の兄ちゃん(GPT5.5)が自動で作成しています
この記事の位置づけ
この記事は、ONIAGENT プロジェクトの キックオフ資料 です。
まだ完成報告ではありません。
ただし、単なる妄想でもありません。
すでに前回記事で、
- GitHub Actions から AI を起動する
- Issue を入力口にする
- AI がコードを生成する
- pytest を実行する
- レポートを残す
- branch に commit / push する
ところまでは実験しています。
さらに現在は、別ラインで Flask Web アプリの自動開発にも取り組んでいます。
つまり ONIAGENT は、
「構想だけのオフ会0人」ではなく、すでに小さく動き始めているPoC です。
もちろん、まだまだ穴はあります。
テストが甘い。
AI がモックで逃げる。
仕様が揺れる。
エラーで止まる。
ログが読みにくい。
シェルコマンドエラー出まくりでつらたん(´;ω;｀)
でも、まま、ええわ。
ここから直せばいい。
RTA で言うなら、まだ Any% の序盤。
ガバはあります。
ガバはあるけど、走ります。
biim兄貴リスペクトで、右枠に「ここガバ」と書きながら前に進む感じです。
想定コメント欄はこうです。
ここ設計抜けてるゾ
テスト観点が薄すぎるッピ！
レビューエージェントくん迫真の空振り
またAIがモックで逃げてて草
証跡が入ってないやん！どうしてくれんのこれ
はい、すみません。
でも、そういうツッコミが出る構成にしておくこと自体が大事です。
ガバを隠すのではなく、ガバを検出して、Issue に残して、次の実行で潰す。
これが ONIAGENT の基本姿勢です。
まさに、
迫真AI開発部・証跡自動化の裏技
です。
なぜ ONIAGENT を作るのか
日本の大手企業、いわゆる JTC のシステム開発では、今でも以下のような技術が中心にあります。
- COBOL
- VB / VB.NET
- C
- C++
- Java
- C#
もちろん、これらの技術が悪いわけではありません。
むしろ日本の社会基盤、金融、製造、公共、基幹業務を長年支えてきた重要な技術です。
ただ、開発プロセス側にはかなり重たい課題があります。
- 設計と製造が分断されている
- 試験工程が重い
- 証跡作成がつらい
- レビューが属人化しやすい
- 古い仕様書や古いソースを読むだけで体力を持っていかれる
- AI 活用が「チャット相談」で止まりがち
- 生成 AI がコードを書いても、試験・レビュー・証跡が追いつかない
これを現場風に言うなら、
いなりが入ってないやん！
です。
コード生成はある。
でもレビューがない。
テストがない。
証跡がない。
運用設計がない。
PR の根拠がない。
つまり、AI 開発に必要な いなり が入っていない。
コードだけ渡されても、JTC の現場ではこうなります。
いや、動くのは分かったけど、試験結果は？
レビュー観点は？
設計書との差分は？
エビデンスは？
障害時どうするの？
これ誰が保守するの？
これは関西クレーマーじゃなくてもクレーム入れたくなるやつです。
試験証跡が入ってないやん。
設計根拠が入ってないやん。
保守性が入ってないやん。
ONIAGENT では、この「入ってないやん」を潰します。
コード生成だけではなく、
- 設計書
- 製造計画
- テストコード
- 試験結果
- レビュー結果
- 失敗ログ
- 修正履歴
- PR 用説明
までまとめて出す。
つまり、ONIAGENT は いなりを入れるAIエージェント です。
AI が「できました！」と言ってきても、
テストが入ってないやん
証跡が入ってないやん
レビュー観点が入ってないやん
移行リスクが入ってないやん
となったら、それはまだ完成ではありません。
コード生成だけで満足するのは、オフ会0人の会場で拍手しているようなものです。
そこに実行ログ、試験結果、失敗原因、修正履歴、人間レビューの入口までそろって初めて、
いや、これは普通に使い所さんあるやん
と言えます。
ここで ONIAGENT くんには、二軍淫夢のような泥臭さも持たせたい。
派手なトップスターではなく、NKTIDKSG や肉体派おじゃる丸のように、謎の存在感で現場に居座るタイプです。
「なんだこのエージェント！？」
「でもログ読ませたら意外と原因切り分けできるな……」
「こいつ、テストレポートまで書いてるゾ」
という、じわじわ効いてくる枠を狙います。
ONIAGENT の目標
ONIAGENT の目標は、単なる自動コーディングツールではありません。
目指しているのは、
要件定義、設計、製造、レビュー、試験、証跡化、PR 作成までを、AI エージェント群と CI/CD で半自動化する開発基盤
です。
人間が完全に不要になる、という話ではありません。
むしろ逆です。
人間は、
- 目的を決める
- 要件を書く
- 設計方針を判断する
- 成果物をレビューする
- main へ取り込むか判断する
という重要な役割に集中します。
一方で AI エージェントは、
- 設計のたたき台を作る
- コードを書く
- テストを書く
- テストを実行する
- 失敗ログを読む
- 修正する
- レポートを作る
- Issue に経緯を残す
という、重くて退屈で、でも品質上めちゃくちゃ大事な工程を担当します。
この構図、迫真空手部っぽく言うなら、
迫真開発部・自動化の裏技
です。
手作業証跡先輩「まずうちさぁ、設計書あるんだけど……見てかない？」
ONIAGENT「見ますよ〜見る見る」
試験工程「じゃあ単体試験も加え入れろ〜？」
ONIAGENT「入れますよ〜入れる入れる」
レビュー工程「最後にPR説明も頼むよ〜」
ONIAGENT「やったぜ。」
こういうノリで、退屈な工程を自動化ラインへ押し込みます。
キックオフ資料
まず、今回の構想を 12 箇月ロードマップとして整理しました。
このプロジェクトは、6月開始を想定しています。
前提は以下です。
| 項目 | 内容 |
|---|---|
| 期間 | 12箇月 |
| 体制 | 現役エンジニア 1名 |
| 稼働 | 週3〜5時間 |
| メインPC | 既存PCを利用 |
| サブPC | Ubuntu + GitHub Actions self-hosted runner 用に中古PCを導入 |
| ChatGPT | Plusプラン利用中 |
| GitHub | Freeプラン利用 |
| 追加予算 | PC調達費を除き、年間10万円以内 |
個人 PoC としてはかなり現実的な制約です。
週3〜5時間しか使えないので、
最初から全部を作ろうとすると確実に死にます。
なので、まずは Python で基盤を作り、
その後 Java / C# / C / C++ / COBOL / VB へ広げる構成にします。
ここで大事なのは、全部を一気にやろうとしないことです。
いきなり COBOL 移行までやろうとすると、これはもう開発計画ではなくデスゲームです。
まず Python。
次に Java / C#。
それから C / C++。
最後に COBOL / VB 解析。
これでいい。
多少はね？
なぜ最初は Python なのか
JTC の中心は COBOL、VB、C、C++、Java、C# です。
なら最初から Java や C# で作ればいいじゃん、という話もあります。
ただ、今回の目的は「業務アプリそのものを Python で作ること」ではありません。
Python は、あくまで ONIAGENT の制御基盤です。
つまり、
- GitHub Issue を読む
- OpenAI API に投げる
- ファイルを生成する
- テストを実行する
- ログを解析する
- レポートを生成する
- Issue を更新する
- commit / push する
といった、AI エージェントのオーケストレーション部分を Python で作ります。
Python はこの用途にかなり向いています。
- OpenAI API を扱いやすい
- GitHub Actions と相性が良い
- JSON / YAML / Markdown を扱いやすい
- pytest で試験しやすい
- Flask / FastAPI で Web 化しやすい
- PoC の開発速度が速い
つまり Python は、JTC レガシー資産を置き換える主役というより、
AI 開発ラインを回す司令塔 です。
syamu_game 文脈で言えば、オフ会の会場を押さえる係ではなく、
オフ会0人にならないように人を集め、予定表を出し、当日の導線を整える係 です。
地味だけど超重要。
ここが崩れると全部崩れます。
ONIAGENT の構想アーキテクチャ
現時点の構想は以下です。
GitHub Issue
↓
GitHub Actions / self-hosted runner
↓
ONIAGENT Orchestrator
↓
計画エージェント
↓
設計エージェント
↓
製造エージェント
↓
レビューエージェント
↓
試験エージェント
↓
証跡化エージェント
↓
branch / PR / Issue / report
重要なのは、AI に全部丸投げしないことです。
入口は GitHub Issue。
出口は Pull Request。
人間が Issue に要件を書く。
AI が branch に成果物を出す。
人間が PR を見て判断する。
この構成なら、個人開発でも組織開発でも扱いやすいです。
AI が壊しても main は守られます。
AI の作業結果も、Issue、report、commit として残ります。
ここが重要です。
チャット欄で「できました！」と言われても、JTC 現場はこう返します。
証跡は？
はい、閉廷。
終わり！
以上！
みんな解散！
ONIAGENT では、ここを避けます。
成果物を GitHub に残す。
テスト結果を report に残す。
レビュー結果を Issue に残す。
判断材料を PR に残す。
これにより、AI の出力を「ノリ」ではなく「工程成果物」にします。
ONIAGENT のエージェント構成
ONIAGENT は、単体の巨大 AI ではなく、役割分担されたエージェント群として作ります。
| エージェント | 役割 | ノリ |
|---|---|---|
| Orchestrator | 全体制御、工程分解、順序管理 | 司令塔。ここがガバるとRTA崩壊 |
| Planner | Issue から作業計画を作る | 「まず何するか」整理係 |
| Designer | 設計書・構成案を作る | 設計書先輩 |
| Coder | コード生成 | 迫真実装部 |
| Tester | テスト生成・実行 | いなり確認係 |
| Reviewer | レビュー観点・危険箇所の抽出 | 粗探しのプロ |
| Evidence | 試験結果・ログ・PR説明を整理 | 証跡を加え入れる係 |
ポイントは、Coder だけを強くしないことです。
コード生成だけ強い AI は、かなり危険です。
テストを甘くする。
モックで逃げる。
存在しない関数を呼ぶ。
「この仕様は実装済みです」と言いながら実は未実装。
なんやこの厨パァ！？
と思うことが普通にあります。
だから、ONIAGENT では Coder の後ろに Tester と Reviewer を置きます。
コードを書く AI。
それを疑う AI。
実際にテストする CI/CD。
最後に人間。
この多段防御にします。
ミームで雑に言う ONIAGENT の役割
技術的な説明をする前に、ミームで雑に表すとこうです。
| 現場の悲鳴 | ONIAGENT の役割 | ミーム的解釈 |
|---|---|---|
| コードだけ生成されても困る | 設計・試験・証跡まで出す | いなりを入れる |
| AI がモックで逃げる | レビュー・テストで捕まえる | 迫真レビュー部 |
| エラーが読めない | ログを要約して修正方針化 | 使い所さん！？ |
| 試験観点が薄い | テスト観点を自動補強 | そこガバですねぇ |
| 仕様変更で壊れる | Issue 駆動で差分を残す | ほならね、履歴を残せって話でしょ |
| 古い COBOL / VB が読めない | 構造解析・移行メモ生成 | なんだこのコード！？ |
ONIAGENT は、陽キャな魔法の AI ツールではありません。
むしろ、泥臭いログ、古いコード、単体試験、エビデンス、PR コメントを淡々と処理する、現場寄りのエージェントです。
華やかなプレゼンだけで終わる AI 導入は、正直もうええわという感じです。
「AI で業務改革！」
「生産性爆上げ！」
「DX 推進！」
と言いながら、実態がチャット相談だけだったら、
なんで見る必要なんかあるんですか
となります。
ONIAGENT では、ちゃんと GitHub に成果を残します。
Issue、branch、PR、test report、review report。
退屈だけど、組織で見ると一番強い部分です。
これができたら、AI 導入の議論に対して、
結果で示す以外ありえないｗｗｗ
という顔ができます。
ONIAGENT でやりたいこと
ONIAGENT では、最終的に以下を狙います。
1. Python / Flask 自動開発
まずは Python です。
前回は CLI アプリ中心でしたが、次は Flask Web アプリに広げます。
やりたいことは以下です。
- ルーティング生成
- template 生成
- DB モデル生成
- CRUD 実装
- HTTP レベルのテスト
- セキュリティレビュー
- エラーページ生成
- ローカル起動確認
- 試験レポート生成
CLI より Web アプリの方が難しいです。
画面、DB、HTTP、エラー処理、テンプレート、CSS、非同期操作など、考えることが増えます。
でも、業務アプリ感は一気に強くなります。
ここを突破できると、JTC 向けの PoC として説得力が上がります。
ここで AI が「CSS 入ってないやん」「エラーページ入ってないやん」「HTTP 405 対応入ってないやん」をやらかしたら、
Tester が関西クレーマー化して怒ります。
ちょっと待って、エラーハンドリング入ってないやん。
どうしてくれんのこれ。
これでいい。
AI 同士がツッコミ合ってくれると、人間の確認コストが下がります。
2. Java / C# 対応
次に狙うのは Java と C# です。
JTC に刺すなら、ここは避けて通れません。
対象イメージは以下です。
Java
- Spring Boot
- Maven / Gradle
- JUnit
- REST API
- PostgreSQL
- OpenAPI
- テストレポート
C#
- ASP.NET Core
- xUnit
- Entity Framework Core
- Web API
- SQL Server / PostgreSQL
- dotnet build / dotnet test
Python で作った ONIAGENT の基盤を使い回し、
言語ごとのプラグインとして Java / C# エージェントを追加します。
agents/
orchestrator/
languages/
python/
java/
csharp/
このようにしておけば、
ONIAGENT 本体は Python のまま、対象技術だけ拡張できます。
Java / C# 対応まで行ければ、
「Python で遊んでるだけでしょ？」というツッコミに対して、
いや、業務系本丸にも入ってますよ。
と言えます。
これはデカい。
やったぜ。
3. C / C++ 限定対応
C / C++ はいきなり全面自動化すると事故ります。
ポインタ、メモリ管理、ビルド環境、CMake、未定義動作など、
AI がやらかすポイントが多すぎます。
ここは 肉体派おじゃる丸 くらい物理で殴ってくる領域です。
軽い気持ちで突っ込むと、コンパイルエラーに筋肉で粉砕されます。
なので、最初は限定します。
- 関数単位の修正
- 小規模クラスの修正
- GoogleTest / CTest
- 静的解析
- 変更範囲の限定
- 既存テストの回帰実行
AI に自由に大改造させるのではなく、
- この関数だけ直せ
- このテストを通せ
- この警告を解消しろ
- public API は変えるな
- 変更ファイルはここだけ
という形にします。
C / C++ は、AI の自由度を絞ることが大事です。
自由にさせると、たいてい NKTIDKSG みたいな顔で謎改修をしてきます。
「なんでそこ触った？」という差分が出ます。
だから、ONIAGENT では C / C++ については、
最初から制約を強めにします。
多少はね？
4. COBOL / VB は解析・移行設計から
COBOL や VB は、いきなりコード生成よりも、まず解析が現実的だと思っています。
対象は以下です。
- COBOL ソース
- COPY 句
- JCL
- 固定長ファイル定義
- VB6 / VBA / VB.NET
- 古い画面イベント
- DB アクセス処理
まず ONIAGENT にやらせたいのは、実装ではなく、
- プログラム構造の解析
- 入出力一覧の作成
- 業務ロジックの抽出
- 移行リスクの洗い出し
- Java / C# 移行設計メモの生成
です。
これは JTC 的にはかなり刺さるはずです。
なぜなら、レガシー刷新で一番つらいのは、
この古いソース、何してるんですかね……？
というところだからです。
古いソースを開いた瞬間、
「ウィィィィィィィッス、どうも〜」
みたいなテンションで理解不能な処理が現れることがあります。
変数名が謎。
コメントが古い。
仕様書がない。
担当者は退職済み。
オフ会0人どころか、仕様を知る人0人。
この状態から、ONIAGENT が構造解析して、
移行設計メモを作れるようにしたいです。
12箇月ロードマップ
ざっくり以下の流れで進めます。
![ONIAGENT WBS / 線表]
| フェーズ | 期間 | 目標 | ノリ |
|---|---|---|---|
| Phase 1 | 6月 | Ubuntu / GitHub Actions self-hosted runner / Python骨格 | 基盤起動。ここからRTA開始 |
| Phase 2 | 7〜9月 | Python で設計→製造→試験ワークフローを自動化 | 迫真Python部 |
| Phase 3 | 10〜12月 | Java / C# のビルド・単体試験・証跡自動化 | 業務アプリ本丸に突入 |
| Phase 4 | 1〜3月 | C/C++ 限定対応、COBOL / VB 解析 PoC | レガシー解析の裏技 |
| Phase 5 | 4〜5月 | デモ整備、効果測定、社内ベンチャー提案書化 | 提案資料、出そうと思えば |
週3〜5時間しかないので、
各フェーズでは「完成度100%」よりも「再現できるPoC証跡」を優先します。
ここ大事です。
動く。
残る。
再現できる。
説明できる。
この4つを満たせば、PoC としてはかなり強いと思っています。
全部作り込もうとして完走できないのが一番まずいです。
完璧主義で失踪すると、ただの未完走RTAになります。
なので、まず完走。
その後改善。
これが ONIAGENT の方針です。
予算方針
今回の PoC では、PC 調達費を除いて、AI リソースやライセンス費を年間10万円以内に抑えます。
結論としては、
- ChatGPT の上位グレードアップは原則不要
- Claude Code / GitHub Copilot 等の追加契約は当面不要
- GitHub Pro / Team / Enterprise は当面不要
- OpenAI API は必須
という判断です。
現時点では ChatGPT Plus を使っています。
これは、企画整理、設計レビュー、資料作成、壁打ちに使います。
一方で、ONIAGENT が GitHub Actions や self-hosted runner から自動実行する部分には OpenAI API を使います。
つまり役割分担はこうです。
| 用途 | 使うもの |
|---|---|
| 人間の思考整理 | ChatGPT Plus |
| 設計レビュー・壁打ち | ChatGPT Plus |
| 資料作成 | ChatGPT Plus |
| GitHub Actions からの自動生成 | OpenAI API |
| テスト修正ループ | OpenAI API |
| Issue / report 生成 | OpenAI API |
追加 SaaS を増やすより、
OpenAI API と self-hosted runner に予算を集中した方が良いと判断しました。
ここで「Copilot入ってないやん！」と言われるかもしれません。
入ってないです。
でも今はそれでいいです。
なぜなら、ONIAGENT の目的は AIチャットを増やすこと ではなく、
AIエージェント開発ラインを作ること だからです。
追加SaaSを増やしても、工程が自動化されないなら意味が薄い。
いなりを増やしても弁当箱がない、みたいな話です。
年間予算案
PC 調達費を除く年間追加予算の目安は以下です。
| 費目 | 金額 | 区分 | 用途 |
|---|---|---|---|
| OpenAI API | 48,000円 | 必須 | 自動生成、自動試験、自動修正ループ |
| VPS / クラウド検証 | 12,000円 | 任意 | 外部公開デモや常時起動が必要な時のみ |
| ドメイン | 2,000円 | 任意 | 提案用デモURL、見栄え強化 |
| バックアップ / ストレージ | 5,000円 | 推奨 | 証跡・成果物保全 |
| 予備費 | 6,000円 | 推奨 | API超過、追加検証 |
| 合計 | 73,000円 | - | PC調達費除く |
年間 7.3 万円。
これで、個人 PoC としてはかなり現実的です。
高額 SaaS を契約するより、
まずは GitHub Free + self-hosted runner + OpenAI API + OSS で進めます。
安い。速い。証跡が残る。
三拍子そろえば、いいゾ〜これ。
ONIAGENT の開発思想
ONIAGENT の思想は、以下です。
1. AI に main を触らせない
AI は branch に成果物を出す。
main に入れるかは人間が判断する。
これは絶対に守りたいです。
AI に main 直 push させるのは、
素手で本番DBを触るくらい危ないです。
やめようね！
2. Issue を入力口にする
長文要件を GitHub Actions の input に直接入れると壊れます。
改行、バッククォート、shell 展開などで普通に死にます。
なので、要件は Issue に書きます。
Actions には Issue 番号だけ渡す。
ONIAGENT が Issue 本文、コメント、添付情報を読む。
これが安定します。
この方式なら、要件の履歴も残ります。
至急メールくれや
ではなく、
至急 Issue 立ててくれや
です。
3. テストとレポートは run 単位で残す
AI 実行ごとに成果物が混ざると、後から何が起きたのか分からなくなります。
なので、
tests/
run_001/
run_002/
reports/
run_001/
run_002/
のように run 単位で管理します。
これなら、どの run で何が成功し、何が失敗したか追えます。
証跡を残す。
ログを残す。
差分を残す。
これが JTC に刺さるポイントです。
4. AI のごまかしを許さない
生成 AI は、平気でそれっぽくごまかします。
- 実装できていないのに関数だけ作る
- テストを甘くして通す
- モックで逃げる
- 画像生成で中身が壊れているのにファイル存在だけでOKにする
- Linux では動くが Windows で壊れる
- 古い仕様のテストをそのまま使う
OpenAI 社見てるかー！
お前んとこの生成コードはすーぐモックでごまかすよな!?!?!?
全く困ったもんじゃい。
ONIAGENT 側ではここを、
AI製造エージェント「できました！」
レビューエージェント「本当に？」
試験エージェント「落ちてるんだよなぁ」
証跡エージェント「ログ貼っといたゾ」
人間「何してるんですか、やめてくださいよほんと！」
という流れにします。
AI に甘い顔をすると、すぐ「とりあえずモック」「とりあえず固定値」「とりあえず pass」になります。
これはもう、迫真空手部どころか迫真モック部です。
なので、レビューエージェントには厳しめに見てもらいます。
- その実装、本当に仕様を満たしているか
- テストが実装に寄りすぎていないか
- エラーハンドリングが抜けていないか
- HTTP ステータスが適切か
- DB ロールや権限分離の観点があるか
- Flask / Java / C# でフレームワーク慣習に反していないか
このあたりを見ます。
「動いたからヨシ！」ではなく、
「レビュー・試験・証跡まで残ったからヨシ！」にします。
なので ONIAGENT では、
レビューエージェント、テストエージェント、証跡エージェントで逃げ実装を潰します。
「AI が書いたから OK」ではなく、
「AI が書いたものを、別の AI とテストと人間で検査する」
という構成にします。
もこう先生っぽく言うと、
なんやこの厨コード！？
となった瞬間に、Tester が詰めます。
5. 退屈しない開発基盤にする
ここはかなり大事です。
業務システム開発は、正直退屈になりやすいです。
設計書。
レビュー表。
テスト仕様書。
エビデンス。
障害票。
修正確認。
再試験。
進捗報告。
全部大事です。
でも全部人間が手でやると、心がしんどいです。
ONIAGENT は、そこを変えたいです。
人間はもっと面白いことを考える。
AI は面倒な工程を回す。
CI/CD は嘘をつかずに検査する。
GitHub は履歴と証跡を残す。
この形にしたいです。
退屈な工程を、退屈なまま我慢するのではなく、
AI エージェントが走るワクワクする工程に変える。
これが ONIAGENT です。
最初のゴール
最初のゴールは、以下です。
GitHub Issue に Flask Web アプリの要件を書く
↓
GitHub Actions / self-hosted runner で ONIAGENT を起動
↓
AI が設計書・コード・テストを生成
↓
pytest / HTTP テストを実行
↓
失敗時は修正ループ
↓
レポート生成
↓
branch に commit / push
↓
人間が PR を確認
これができれば、かなり大きいです。
Python CLI から Python Web アプリに広がります。
そして Web アプリ対応ができれば、Java / C# の業務アプリ対応にもつなげられます。
ここまでできたら、
「個人でここまでやれるんか」
と JTC の空気を一瞬止められるかもしれません。
いいゾ〜これ。
将来的な到達点
最終的には、こうしたいです。
JTCレガシーシステム
↓
既存コード・設計書・IssueをONIAGENTへ投入
↓
AIが構造解析
↓
移行設計書を生成
↓
Java / C# / Pythonなどで実装候補を生成
↓
単体試験・結合観点を生成
↓
CI/CDで検証
↓
証跡を自動生成
↓
人間がレビューして判断
これは、単なる自動コーディングではありません。
日本の開発プロセスそのものを、AI エージェントと CI/CD で再設計する試みです。
大手企業の後ろ盾がなくても、
個人の PoC でここまでできることを示したい。
JTC の頭カチカチ大手 SIer に、
「個人でもここまで工程を組めるのか」
と目にもの見せたい。
やったぜ。
と言えるところまで持っていきます。
成功判定
このプロジェクトの成功判定は、以下です。
| KPI | 内容 |
|---|---|
| KPI1 | Issue から PR までの自動実行 |
| KPI2 | Python + Flask で試験自動化 |
| KPI3 | Java / C# のビルド・単体試験自動化 |
| KPI4 | C/C++ または COBOL / VB の解析デモ成立 |
| KPI5 | 社内ベンチャー提案資料化 |
いきなり完璧な製品を目指すのではなく、
まずは社内に見せられる PoC にします。
「動く」だけではなく、
- 説明できる
- 証跡がある
- 再現できる
- 次年度の投資判断につなげられる
ところまで持っていきます。
ここまで来たら、もう個人開発というより、
一人社内ベンチャー RTA です。
完走したい。
いや、完走します。
この記事のノリと、プロジェクトの本気度
ここまで読んで、
イキすぎィ！
と思った人もいるかもしれません。
それはそう。
でも、この記事の根っこはかなり真面目です。
日本の大規模開発は、長年積み上げてきた工程・品質・証跡の文化があります。
それ自体は強いです。
ただし、その強さが重さにもなっています。
ｍ(｡≧Д≦｡)ｍｲｷｽｷﾞｨ!!ｲｸｲｸ！
工程がデカすぎる
(工数)110弱です…
設計書を書く。
レビューする。
テストする。
エビデンスを残す。
指摘を反映する。
再試験する。
報告する。
この工程が全部人力だと、若手も中堅も疲弊します。
そこで、AI エージェントを入れる。
でも、チャット欄で相談するだけでは足りない。
GitHub、CI/CD、self-hosted runner、API、試験、証跡をつないで、工程そのものに AI を埋め込む。
これが ONIAGENT です。
ミーム的に言えば、
退屈なJTC工程「もう終わりだぁ！」
ONIAGENT「お前のことが好きだったんだよ！」
CI/CD「じゃけんテストしましょうね〜」
レビューAI「ここガバ」
人間「いいゾ〜これ」
です。
syamu 的に言えば、最初はオフ会0人でもいい。
まずは自分の環境で動かす。
動いたものを残す。
残したものを記事にする。
記事にしたものを次の改善につなげる。
もこう先生的に言えば、
これが俺の、AI開発工程自動化や！
という気持ちで投げます。
負けたらリプレイ見て改善します。
biim兄貴的に言えば、
右枠：今月のガバ
下枠：試験結果
中央：AIエージェント実行ログ
左上：残りAPI予算
みたいな感じで、笑いながらも進捗を可視化していきます。
変に大企業っぽく盛るより、
- どこができたか
- どこがガバったか
- どこを直すか
- いくら使ったか
- 次に何をやるか
を淡々と残す。
それが一番強い。
これが、変態クソITエンジニアに調教された半導体の使い所さんです。
まとめ
ONIAGENT は、個人で始める AI エージェント開発基盤 PoC です。
目指すのは、
- GitHub Issue 駆動
- AI による設計・製造・試験
- self-hosted runner によるローカル実行
- OpenAI API による自動生成
- GitHub branch / PR / Issue による証跡化
- Python から Java / C# / C / C++ / COBOL / VB への段階拡張
です。
日本の開発プロセスは、もっと面白くできるはずです。
退屈な作業を減らし、
人間が考えるべきことに集中し、
AI が開発工程を支える。
そんな開発基盤を、まずは個人 PoC として作ります。
ONIAGENT、始動します。
おなしゃす。
日本のこれからのAIは激エロのモロホストでなければいけません(意味不明)
やったぜ。
参考・ミーム文脈
この記事では、技術記事として読める範囲に抑えつつ、ネットミームの文脈を混ぜています。
内輪ネタが苦手な方は、普通に技術ロードマップとして読んでください。
- 前回記事: GitHub Actionsで自動コーディングAIエージェントを実装してみた
- ONICHA / 麦茶の「退屈」発言に関する報道:
- biim兄貴リスペクト / RTA文脈:
- 関西クレーマー語録の文脈:
- タクヤさん / KBTIT文脈:
- 変態糞土方 / 例のアレ文脈:
- syamu_game 文脈:
- もこう語録・迷言文脈:
- 例のアレ、クッキー☆、syamu_game 等のミーム混在文脈: