日本の開発プロセスを変える。退屈しないワクワクするAIエージェント「ONIAGENT」を実現

はじめに

ITエンジニアのたくわんです。
26歳、(元)学生です。

前回の記事では、GitHub Actions と OpenAI API を使って、AI エージェントがコーディング、レビュー、修正、単体テスト、レポート作成、Issue 起票、commit / push まで行うワークフローを作りました。

ざっくり言うと、

GitHub Issue に要件を書く
GitHub Actions で AI ワークフローを起動する
AI が branch に成果物を生成する
レビューやテストに失敗したら修正ループを回す
試験結果を Markdown / HTML レポートとして残す
最後は人間が Pull Request を見て判断する

という構成です。

前回記事はこちらです。

GitHub Actionsで自動コーディングAIエージェントを実装してみた

そしてここから、いよいよ次の段階に進めます。

その名も、

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文脈:
- https://kimu3.net/20170129/6221
- https://news.denfaminicogamer.jp/interview/190514c
関西クレーマー語録の文脈:
- https://leisurego.jp/archives/389627
タクヤさん / KBTIT文脈:
- https://kimu3.net/20170219/6647
変態糞土方 / 例のアレ文脈:
- https://w.atwiki.jp/niconicomugen/pages/8668.html
- https://note.com/reo_n_serious/n/n123a6d5c04f5
syamu_game 文脈:
- https://note.com/qqateaocnnejp/n/nfe3c16bb495f
もこう語録・迷言文脈:
- https://w.atwiki.jp/mokou1115/pages/96.html
例のアレ、クッキー☆、syamu_game 等のミーム混在文脈:
- https://kimu3.net/20160903/4978