OSS開発を通じて考える、AI時代開発のこれから / The Future of Software Development in the AI Era

## 発表

https://seb-sapporo.connpass.com/event/398613/

## 紹介したOSS

- https://github.com/tooppoo/git-kura
- https://github.com/tooppoo/reportage
- https://github.com/tooppoo/installerer

1. OSS開発を通じて考える AI開発のこれから 2026-07-21 SAPPORO ENGINEER BASE #15 #seb_sapporo @Philomagi 1 / 16
2. 発表者 @Philomagi WEB系プログラマ 自称フロントエンド寄り 最近は Rust とか Go とか 2 / 16
3. 2026年前半に変わったこと Claude や Codex を使い、個人でも複数のOSSを並行して開発できた コードを書くこと自体の負荷は下がった 実装レイヤの代わりに、違うレイヤの負荷が大きくなりつつある 3 / 16
4. 負荷の比重が大きくなったレイヤ 複数AIエージェントの作業をどう分離するのか どこまでをAIエージェントに任せ、どこからは任せないのか 生成された実装が正しいかを、どう確かめるのか ※ 作業状態の管理、AIに委任する範囲、生成結果の不確実性が、問題の中心になった 4 / 16
5. 開発スタイル・方針の変化 複数のAIエージェントに並行で作業させる 「生成する仕組み」をAIに生成させる プログラム、ドキュメントなど 実装結果は逐語的に読むより、全体構造と入出力の結果検証を重視 並行実装、自動生成の実装、入出力契約の検証に重点が移動 5 / 16
6. 開発における2つの領域 ファジー＝揺れが残り、同じ入力が必ずしも同じ結果とならない領域 決定論的＝同じ入力なら同じ結果になる領域 ファジー 人間とAIが 探索・判断する 決定論的 プログラムで 自動化・定式化する ファジーな領域が残ることは受け入れつつ、決定論的に扱える領域を増やす 6 / 16
7. OSS開発を通じてのアプローチ 並行作業の衝突を防ぐ コードを生成するコード 入出力特化のE2E → → → git-kura installerer reportage ファジーな領域を減らす + 人間が注意を払う範囲を限定するためのOSS開発 7 / 16
8. reportage : 入出力特化のE2Eテスト 入出力を実装言語から独立して検証する 標準出力・エラー出力・終了コード・ファイルの検証に特化 AIが内部実装を頻繁に変えるほど、外部から見た挙動を固定する価値が上がる 詳細ではなく、観測可能な振る舞いの検証に焦点を当てる 人間は、観測可能な振る舞いへ重点的に注意を向ける 8 / 16
9. reportage : 実際のコード例 9 / 16
10. git-kura : 並行作業の衝突検知 worktree を作業単位として分離 変更対象のファイルを明示的に宣言させる 競合を機械的に検出し、非ゼロ終了でAIの処理を止める コンフリクト発生後ではなく、編集・コミット前に止める AIの出力・作業内容は揺れても、作業領域と競合状態は機械的に判定する 10 / 16
11. git-kura : 実際の衝突ログ 11 / 16
12. installerer : installerの機械的生成 install.sh をAIから生成すると、入力規約や出力結果がブレる可能性 結果を安定して保障できない install.sh を生成するためのツール = installerer を、AIを使って作成 installerer は、同じ入力には常に同じ shell script を生成する コードではなく、コードを作るコードをAIで作る コードによるコード生成結果は安定して検証可能 12 / 16
13. installerer : web UI 13 / 16
14. 3つを統合するモデル 曖昧な要求を、人間とAIで探索する ↓ 作業の制約を明示 ↓ git-kura 安定した結果を得る仕組み作り installerer ↓ 外部挙動の重点的検証 reportage 制約を明示し、結果を安定させ、外部契約に注力する 14 / 16
15. これまでとこれから （これまで）AIにより、開発速度と並行性は向上した 問題の中心は、実装よりも並行実装・委任範囲・生成結果の不確実性へ （これから）ファジーな領域と決定論的な領域を分離し、後者を検証可能にする ファジーな領域は無くせないことを前提に、いかに決定論的領域に寄せ、注力すべき 範囲を絞るか AIの登場により、現実的な範囲になってきた？ AIを前提としつつ、検証可能・把握可能な仕組みを構築する開発へ 15 / 16
16. これから作りたいもの 仕様の記述に形式手法を取り入れたい 形式手法で証明された仕様と、実装・テストの対応関係がネック 仕様-テスト（戦略、設計、ケース）-E2E実装を紐づけるツールを作る？ それぞれのartifactをnominal typeと見なして、リンクさせる 関連付けが保証された仕様・テスト・E2E実装 仕様、テスト、E2E実装を見れば「OK」と判断できる環境づくりが目標 16 / 16