AI向けWorkflow設計で感じたプロジェクト共通化の難しさ

対象読者

• AIコーディングを導入・検討している開発チーム

• AIエージェント向けのリポジトリ構成に悩んでいる人

前置き

AIコーディングを導入してから、「Workflowはどこに置くべきなのか」という話になりました。

私は各プロジェクト配下にWorkflowを配置しました。

projects/
├── project-a/
│   └── workflow/
└── project-b/
    └── workflow/

理由は単純で、プロジェクトごとに以下の内容が違いました。

• 使用言語

• アーキテクチャ

• Backlog

• ディレクトリ構成(プログラム、設計書含む)

しかし、この構成に対して「Workflowはもっと抽象的なものでは？」という他の人からフィードバックをいただきました。

この時、人によって「Workflow」という言葉の抽象度が異なることに気付きました。

私が考えていたAI向けWorkflow

具体として私が考えていたWorkflowは、AIがそのプロジェクトを開発するための実行手順です。

例えば、以下のようなことをしてほしいとして、AIが実際に行動する流れをWorkflowとして定義していました。

1. プロジェクト構造を確認する

2. Backlogを確認する

3. 設計する

4. 実装する

5. レビューする

Workflowはもっと抽象的なものでは？というフィードバックをいただいた時に、私はプロジェクトに依存しない共通の開発Workflowをイメージされているのだと受け取りました。

振り返ると、お互いにWorkflowという言葉の抽象度が異なっていたのだと思います。

私の環境では、AI向けWorkflowはプロジェクト固有の方が適していると感じています。

例えば、以下のようなプロジェクト構成があったとして、AI活用しても実装方法もレビュー観点も異なります。

Project A

• Java

• Angular

• Vue

Project B

• Golang

• Next.js

そのためAIに共通Workflowだけを読ませると、実装時には使用しない技術の情報までコンテキストに含まれる可能性があります。

• Javaの情報

• Angularの情報

• Next.jsの情報

AIは人間と違い、コンテキストが増えるほど以下の問題が発生しやすくなります。

• トークン消費

• 判断コスト

• 誤った参照

そのため、「必要な時に必要な情報だけを読む」構成の方がAIには向いていると考えています。

従来のソフトウェア設計では、共通化は保守性を高めるための有効な手段です。

一方AIは不要なコンテキストまで読み込むことで、トークン消費や判断コストが増えることがあります。

AIでは「情報を共通化すること」よりも「不要な情報を読ませないこと」の方が重要になる場面があると感じました。

(※企業としてもAI活用した開発予算の観点もあるでしょう。)

後書き

現時点では、AI向けWorkflowはプロジェクト固有の方が開発体験は良いと感じています。

ただし、設計書やディレクトリ構成、開発ルールなどが組織全体で標準化されているのであれば、共通Workflowという選択肢も十分あり得るのかもしれないなぁと整理しつつ記事化しました。

AI時代のMRレビューで考えたこと

お久しぶりです。

ここ最近は、自分で機能開発をする時間よりも、開発プロセスと向き合う時間の方が増えてきました。

具体的には、AIを活用した開発ワークフローの導入や、その効果をどう計測するかといった、開発の仕組みそのものを改善する活動に携わることが多くなっています。

AIワークフローを導入すると「開発速度が上がった」と言われることはよくあります。しかし、実際に何をもって速くなったと言えるのかを定量的に示すのは意外と難しいものです。

似た規模・難易度の機能開発と比較したり、レビュー工数やリリースまでの期間を見たりと、評価方法はいろいろありますが、まだまだ試行錯誤の段階だと感じています。

そんな中で、最近少し気になっていることがあります。

対象読者

AIを活用して日々開発をしているエンジニアの方へ向けた記事となります。

MRレビューで増えたコメント

私は昔から、レビューでは「ここが良かった」「この考え方は良いですね」といったポジティブなコメントを書くことを意識してきました。

もちろん、疑問に思った点や議論したい部分についてコメントを書くこともあります。

ただ最近、その返答として次のようなコメントを見る機会が増えました。

「AIが出力したコードですが、ご指摘のコメントは正しいので修正します。」

「AIの出力結果です。計画モードでも要件を満たしており、セルフレビューでも問題ないことを確認しています。」

もちろん、修正してもらえること自体は良いことです。

ただ、そのコードをなぜ採用したのか、どういう意図でこの実装を選んだのかという説明が少し減ってきたように感じています。

以前であれば、

「こういう理由でこの実装にしました。」

「こういうメリットがあると思って、この形でコミットしました。」

というようなコミュニケーションを自然に取る場面が多かった印象があります。

AI時代だからこそ、人間が考えること

今はAIワークフローの中にGit操作まで組み込まれていて、人間は指示を出し、最後にレビューするだけ、という開発スタイルも珍しくありません。

便利になったことは間違いありません。

ですが、だからこそ「なぜこのコードが良いのか」を説明できることは、以前よりも重要になっているのではないかと思っています。

保守性、可読性、拡張性。

そういった基本的な視点は、AIがコードを書いてくれる時代になっても変わりません。

AIが生成したコードだから採用するのではなく、自分が納得できる理由を持ってGitに乗せる。

そんな姿勢は、これからも大切にしたいと思っています。

強いエンジニアが読めるコードではなく、チームが読めるコード

最近はAIのおかげで、以前ならかなり時間がかかっていたような複雑な実装も比較的簡単に作れるようになりました。

一方で、そのコードを数か月後、あるいは数年後に保守することまで考えられているかというと、少し不安に思う場面があります。

レビューで

「自分は読めるからOK」

と判断することは簡単です。

でも、実際に保守するのは未来の自分かもしれませんし、チームメンバーかもしれません。

チーム全体の平均的なスキルセットで理解・保守できるコードになっているかという部分はセルフレビュー・MRのフローで求められるようになる気がしています。

おわりに

AIによって開発のやり方は大きく変わりました。

ただ、MRレビューを通して感じるのは、「なぜそのコードを採用したのか」を説明できることや、チームで保守できる形を考えることの価値が以前より高まっているように感じるようになり記事化しました。

【ご報告】コミックマーケット108申し込みを行いました

みなさま、お久しぶりです。

コミックマーケット108の申し込みを行いました。

ここ最近23:00〜24:00の時間に帰宅後も案出しをしたり技術調査しててドタバタで、どの案で申し込みするのか結構揉んでいたらギリギリの申し込みになりましたが、なんとか間に合いました。

アイデア出し

• アイデア1つ目：短時間のRPGオンラインゲーム作成本
  • 10分程度で終わる。
  • unity web gl使用
  • 素材はフリーのアセットやらAI使って生成して素材を集める。

• アイデア2つ目：セキュリティ本に関する本

  • CVEの数字高めのもの調査
  • 採用技術整理

調査してみて両方とも面白いアイデアと技術でしたが直近の仕事に活かせそうだなーと思ったので、今回は後者の案で進めてます。

攻撃者の視座も養えますしそれに対する対応とか、ただAIにサジェストされたプログラムを書いている人は危険かもしれません〜ってメッセージを伝える本になると良いなと思いました。

ただ暗い内容の本にしたくはないので、ポップな感じの本で作成予定です。笑

以上、報告になります。

当落発表は少し先ですが、受かっていたら本を気合いで作成します！

また、技術書を作成して売り場に立って良い感じに周りの技術者の方とコミュニケーションとって楽しかったことが多かったので、そういった話や技術的な話をブログに書いていきたいです。

【ご報告】コミックマーケット107に出展いたします。

さて本題に入りますが、この度コミックマーケット107(comic market107)に出展することになりました。

2日目のスペース「南h-34b」で頒布を予定しております。

今回は11月に告知したように、新刊が完成しました。(新刊を落とさなくてよかった...。)

新刊は500円です。

非エンジニアの方に向けては、説明文には文字だけじゃなくてブルアカキャラ同士がお話しするパートを入れてみたりしてます。

あまりパソコンやそういった分野に詳しくないけど、なんとなーく興味がある程度の方でも気軽に立ち読みしたり、技術に興味が持てたりするきっかけになると良いなぁ〜みたいな感覚で見てもらえると幸いです。

エンジニアの方に向けては、10数秒かかっていたAPIレスポンスをミリ秒まで縮めました、本誌の中身が気になる方は、是非是非「サークル名：主任FC」へ遊びに来て下さい。

サンプルページ

 

最後に所管...(ここは告知とは関係ありません)

勢いでコミケ応募したものの新刊を書く時間を捻出できて本当によかったです。

今年に限っては年内を振り返ると思っていた何倍も忙しい年となりました。

お仕事上では悲しいことも何回か起きたり、チーム内の運用や製品提供後の観点での運用の難しさを感じたり、複数の案件を並行して作業している身の人間からすると限られた時間でチーム運用や技術に関する解像度の共有は本当に難しかった...。

(※この手の話はブログや技術書を書いてもっと伝える能力の改善に繋げれるように動いていきたいですね。)

また短い時間で調査〜決断することが多くて、小さな決断から1度決めると変えることが難しい決断を決めたりすることもあり、成長の年でした。

【ご報告&事前告知】コミックマーケット107に出展いたします！

みなさま、お久しぶりです。

唐突なご報告になりますが、縁あってコミックマーケット107(comic market107)に出展することになりました。

そして、コミックマーケットが今回の2025年12月30日～31日開催で50周年イヤーとのことで、めちゃくちゃおめでたい時期にサークルスペースを準備して貰えました！本当に嬉しい限りです。

50周年イヤーに恥じない尚且つ、お手に取った方に楽しんでもらえるような新刊を作ります。

2日目のスペース「南-h34b」で頒布を予定しております。

今回も同人ソフトの島でWeb系の本を頒布いたします。

＜新刊情報＞

また来月コミケ開催日に近い日付になりましたら、新刊の具体な情報を発表させていただきます。

今回もエンジニアの方や非エンジニアの方も楽しめるような本を作ろう！と思って筆(キーボード)を取りました。

現状の方向性だと前作とは違う、以下のようなアプローチを取り入れて新刊を作成に着手しております。

1、印刷所で製本依頼予定

2、Webシステムのパフォーマンス改善を図る本にしてますが、前作とは違う技術的なアプローチを採用

3、ブルーアーカイブのキャラクター同士の会話パートを入れて前作よりも楽しんで読みやすいようなアプローチを取り入れました！

製本予定の印刷所さんは決めており、現在は鋭意新刊制作中です。

皆さん是非当日は本スペースにお立ち寄りいただけますと幸いです。

以上となります、どうか当日はよろしくお願いいたします！

【悲報】コミックマーケット106に落選してしまいました

前置き

まずかなり遅くなってしまいましたが、コミックマーケット105へ弊サークルへ来てくれた方、ありがとうございました。

初めての即売会参加・初めての本作成など色々刺激になり、お友達と本を作れたという達成感はなかなかない体験を得られました。

周りの技術書のサークル様に助けられたことや教えてもらえたこともあり、非常に楽しかったです。

また本を書いてブログよりも多くを語れるため、アウトプットしていて楽しかったです。(※ブログで多くを語るにも記事を分けたりで視認性などの方向を考えてしまいますから...。)

本題

去年の暮れにコミックマーケットへ参加して業務が落ち着いてきたと思ってましたが、思いのほか、年明けはお仕事が落ち着くことなくコミケ106へ申し込みだけして、下準備(お友達にイラスト作成してくれる人、売り子確保)はしていたのですが.....。

次回の本は印刷所に依頼してみよう！と思った矢先、、、、

これは残念でございました。

ただ、今回C106で落ちたからといって本を出すという行為はやめる訳でなく本の大枠は考えていましたので、次回のコミケ107に継続して応募してみようと思ってます。

【ご報告】コミックマーケット105に出展いたします。

お久しぶりです。

ブログの更新がかなり止まっておりましたが、生きております。

最近は比較的に業務が落ち着いてきたこともあり、タイミングを見てこちらのアウトプットも再開したいですね。

さて本題に入りますが、この度コミックマーケット105(comic market105)に出展することになりました。

2日目のスペース「西い-09a」で頒布を予定しております。

今回は同人ソフトの島で、電子工作の本かwebの本どっちにしようか迷ってwebの本にしました。

 

＜新刊情報＞

エンジニアの方や非エンジニアの方も楽しめるような本を作ろう！と思って筆(キーボード)を取りました。

内容はMySqlのDBにいっぱいデータを入れてSQLを発行して、その結果をわかりやすいように説明を入れたり図を作成して見たりました。

 エンジニアの方に向けては、なんとなーく利用しているSQLがどこのリソースを利用して、良い感じに結果を出しているのか？など振り返る契機の本になると良いなぁと思います。

非エンジニアの方に向けては、説明文には文字だけじゃなくてブルアカキャラの挿絵を入れて見てますのであまりパソコンやそういった分野に詳しくないけど、なんとなーく興味がある程度の方でも、是非是非「サークル名：主任FC」へ遊びに来て下さい。

最後に所管...(ここは告知とは関係ありません。)

所管ですがコミックマーケットに参加して技術系の島を見てて私も何か形にして出して見たいなぁと直近で思い申し込んでみました。

もう年末なの早すぎて正直驚きを隠せません、原稿にかける工数をもっと捻出したかったのですが、なんとか本という形になったため初回参加で我ながら頑張ったと自分を褒めました。笑

今(2024/12/21時点)の時間から本の更新をかけると本当に準備が間に合わないため、本を作るのはに難しいとかなり実感しました。

ただブログでも本でも良いのですが、何かの媒体を通して頑張って発信を行うという活動は引き続き行なっていき何かしらの形で世に貢献していきたいです。

このブログで最後あたりに書いた記事がマイクロサービスのこと軽く調べて個人開発でもやっていく〜〜みたいな内容の記事が最後でしたが、実務でGoを利用してマイクロサービスのアーキテクチャをやってみたり、社内向けの記事を書いたり行なって行ったら、はてぶろ更新のできなくなってたので、なんとかこちらにも力を入れれる様になりたいです。