©2024 Kyash Inc. ©2024 Kyash Inc. AIで 浮いた時間で 何をする？ 〜 2026春〜 Developers Summit 2026 2026/02/20 (金) Kyash Inc. VPoE @konifar 

©2024 Kyash Inc. アップデート版です 2 ５ｶｹﾞﾂ! 

©2024 Kyash Inc. この質問から何が思い浮かぶか AIで 浮いた時間で 何をする？ 3 

©2024 Kyash Inc. “5・7・5"ですね 4 A
 I
 で
 浮 い た 時 間 で
 何 を す る ？
 

©2024 Kyash Inc. 浮いた...時間...？ 5 A
 I
 で
 浮 い た 時 間 で
 何 を す る ？
 ｲﾜｶﾝ! 

©2024 Kyash Inc. 6 時間が“浮く"という感覚は実は減ってきている ● 長い時間のタスクを雑に依頼できるようになった ○ あまり細切れではなくなってきている感覚 ○ ニンゲンが共同実行者としての AI に適用してきている ○ AIが進化し、 たとえば Codex は Claude Code と比べて長い時間自走してくれるようになった ● もともとのスキルが高い人ほど、時間が浮くという感覚はあまりないと思う ○ 並列作業になれ、動き方が最適化されると、自分の力が “拡張" された感覚になる ○ アイデアはあるが面倒だったことをとにかくやってくれる拡張手足が手に入った 

©2024 Kyash Inc. この“下の句"を考えたい ● AIでニンゲンの時間は増えたのか ● 時間が増えたとして、短期的にはその時間 をどう活用していくか ● さらに活用できたとして、長期的には我々 はどう“適応"していくか 話すこと 7 ● AIツールやエージェントの活用詳細 ● AIのプロダクトへの適用やAIを前提とし たプロダクト開発 あまり話さないこと 

©2024 Kyash Inc. 小西 裕介 (こにふぁー / @konifar) [Kyash と わたし] ● 株式会社 Kyash で 8年2ヶ月くらい Fintech のプロダクトを作っています ● 直近4年くらいはマネジメントの役割を担っています ● 日々学んだことをブログに書き残したりしています [Kyash と AI] ● Kyash は金融事業ということもあり、 AIの活用どころは一定慎重にはなりつつも、 組織横断のAI推進チームを作っ て検証や整備をしています ● Claude Code や Gemini、 Codex などを利用していて、 経費補助を エンジニアに限らず 月10,000円/人 とっ て推進しています。 最近はエンジニアの部門予算を別途とってよりフレキシブルに実験できるようにしています 8 よろしくお願いします 

©2024 Kyash Inc. 9 目 次 1. 学習 2. 盆栽 <= New!! 3. 問い 4. 禅 Table of contents 

©2024 Kyash Inc. ©2024 Kyash Inc. 1. 学習 10 10 

©2024 Kyash Inc. 11 AIコーディングツールによる生産性向上 ● Opus 4.6 や GPT 5.3 など、 モデルの進化により自己修正能力が飛躍的に向上 ○ CLAUDE.md や AGENTS.md に明記していなくとも、自分でコードを読んでビルドしてテストを書き、ロ グを読んで修正してくる ○ 雑にロングタイムタスクを任せられるようになってきている ● 「コードを書く」 という定義が変わってきつつある ○ 社内でも、直接コードを書くことはもうほとんどなくなったという人も出てきている ○ プログラムのメモリ管理に頭を使うことが減ったように、 考えて工夫する領域が変化してきている 明らかに劇的。 あらゆる前提が変わるほどの変化。 ﾊﾔｲ! 

©2024 Kyash Inc. 12 たとえば小さな実装のワンセット 設計 実装 テスト レビュー コードやドキュメントの調査 設計の壁打ち 見落としの確認 ドキュメントのまとめ ロジックの実装/動作確認 ユニットテスト追加/修正 E2Eテスト追加/修正 Pull Request 作成 仕様齟齬の指摘/修正 コード上の不具合の指摘/修正 

©2024 Kyash Inc. 13 ちょっと前 - ツールとしての利用 設計 実装 テスト レビュー 「◯◯の仕様についてまとめて」 「仕様考慮漏れをチェックして」 「/plan」 「この関数のテスト書いて」 「この実装に合わせて修正して」 「Codexレビューして」 「仕様齟齬をチェックして」 「/hogehoge-review」 

©2024 Kyash Inc. 14 いま - 共同実行者としての伴走 設計 実装 テスト レビュー ● planで既存コードや過去のドキュメントもすべて読み込んで計画を出してくる ○ ある程度のmdやskills、commandの整備をしておけば、 かなり自走してくれるようになった ● めちゃくちゃ物知りだがまだ少し気が回らない新人が、相談相手になる上に率先して動い てくれるようになってきたような感覚 ○ めんどくさい実装をすぐに作ってくれるし、何度修正依頼してもめげない ｽｺﾞｲﾈ! 

©2024 Kyash Inc. 15 劇的な改善ができるはずだが...？ 設計 実装 テスト レビュー コードやドキュメントの調査 設計の壁打ち 見落としの確認 ドキュメントのまとめ ロジックの実装/動作確認 ユニットテスト追加/修正 E2Eテスト追加/修正 Pull Request 作成 仕様齟齬の指摘/修正 コード上の不具合の指摘/修正 設計 実装 テスト レビュー ？ こんな感じでニンゲンの時間が増えたのか？ より “創造的な" 何かができているのか？ ？ 

©2024 Kyash Inc. 16 現状、おそらくそうはなっていないことが多い ● Claude Code が調査している時間、コードを書いている時間、何をしていますか？ ○ なんとなく眺めたりXを見たりしているだけになっていませんか？ ● 生成されたアウトプットに対する確認にどのくらい時間をかけていますか？ ○ AIに振り回されて、振り返ってみるとむしろ時間がかかってしまっていませんか？ ○ 自分の意思決定が雑になっている感覚はありませんか？ ● AIがさまざまなアウトプットを出してくる中で、うまく頭を切り替えられていますか？ ○ コンテキストスイッチが増え、自分のアウトプット総量が思ったより上がらないことはないですか？ ｷﾞｸｯ! 

©2024 Kyash Inc. 17 ニンゲンが“適応"する必要がある ● AIは時を“加速"させる ● 細切れになる時間に対して、ニンゲンが動き方を変えて“適応"しなければならない といっても、そんなに新しい特別な話ではない。 歴史の中で常にニンゲンがやってきたこと。 ● メール中心からチャット中心に移行して起こった“チャット疲れ"と似ている ● 細切れの時間に悩んだり意思決定疲れを起こしたりするのは、マネージャーの普遍的な苦悩のひとつ 

©2024 Kyash Inc. 18 AIを中心とした“適応"とは、自分が“学習"すること ● (現状は) 自分の理解が足りない領域をAIにお任せするのはあまり筋がよくない ○ 逆にある程度理解ができた状態で使うと、自分の能力を拡張するような感覚で生産力が飛躍的に向上する ● AIで生産力を上げられるのは、使いこなす能力がある人だけ ○ AIは増幅器。 AIを活用するなら、よりいっそうニンゲンが学習し続ける必要がある ○ 結局ニンゲンの能力を上げていかないと生産力は上がらない 

©2024 Kyash Inc. 19 学習の仕方を見直す ● 学習の仕方もAIに最適化する ○ 「学習したいことをググってドキュメントや記事を片っ端から開いて全部読む」 みたいなやり方を変えてみる ○ AIのことはAIに聞くのが一番 ○ たとえば Claude Code の /insights コマンド。 利用実態をまとめて改善提案してくれる ● 対話して整理することに慣れる ○ 単に情報を得るだけではない。 学習は“読む"から“対話する"へ変化 ○ 過去の会話の蓄積で自分の特性を知ってもらった上で、 自分の頭の中にある考えをAIと対話しながら整理 し、 定義していく ○ 自分の思考が誘導されすぎないように気をつける必要はあるが、 学習スタイルの大きな変革になる 

©2024 Kyash Inc. 20 何を“学習"するか ● 関連する技術やドメイン、その隣接領域 ○ メイン分野は深く学びつつ、他も広く浅く知ってインデックスを張ること ○ 本や資格試験で体系的に学ぶ価値が上がっている ● AIツール/エージェントの仕組み ○ AIに適切な指示を出すために、AIがどう動いているかを知ること ○ (今は) AIツールを使いこなすための機能やTipsも大事 ● プロダクトマネジメント ○ よりなぜ何を作るかを決める重要性が上がっている ○ アウトカムを強く意識できるようにマインドをアップデートする ● (国語) ○ AIとの対話の中で自分の意図を正確に伝え、 回答を正確に読み取る論理的思考能力が必須 ○ 対ニンゲンと同じ。 本を読み、 対話を重ねることでトレーニングする 

©2024 Kyash Inc. 21 AIで浮いた時間は、 “学習" に使う A
 I
 で
 浮 い た 時 間 で
 何 を す る ？
 学 び 深 め て
 A
 I
 と 歩 む
 「今はAIで浮いた時間はAIをより使いこなせる ように自分の学習の時間にあて、AIとの協業や 自身の学習方法をアップデートするというルー プを回すのがよい」 の意 

©2024 Kyash Inc. ©2024 Kyash Inc. 2. 盆栽 22 22 

©2024 Kyash Inc. 23 AIは積み重ねが大事 ● 自分やチームの仕事のフローを形式化する ○ 構造化されていない情報をもとにした仕事の形式化が可能 ○ デザインルールチェック、 コードレビュー、 セキュリティチェック など ○ ニンゲンの繰り返し業務を形式化し、 未知の業務に取り組む。 それもまた形式化するの繰り返し ● 一気に作り上げるというよりは、 日々触れていく中で少しずつ育てていく ○ スラッシュコマンドやスキルの追加、整備 ○ 日々のやりとりによるワーキングメモリの積み重ね ○ 育てていく習慣ができると、 複利でどんどんよくなっていく 盆栽のように毎日少しずつ愛でて育てる 

©2024 Kyash Inc. 24 これまでもニンゲンがずっとやってきたこと ● エディタ や シェル、 IDE、 CI/CD や README を少しずつ変更しながら育ててきたのと同じ ○ AIの “盆栽" の特性を知って同じように育てていくこと ○ AI が自己補正できるガードレールの整備しておく ○ ミスや指摘の内容を CLAUDE.md / AGENTS.md に追記させる ● “学習" の一部とも言えるが、 自分とチームの明確な成果物になる ○ 再現性のある環境を整備し、チーム共有の資産を皆で育てる 

©2024 Kyash Inc. 25 データを整備する ● データ自体とデータへのアクセス環境が整備する ○ たとえばDBのテーブル/カラムコメントの自動アップデート、 データアクセスの権限整理 など ● ニンゲンがAIへのデータの橋渡し役にならなくて済む状態を作る ○ プロダクトのデータはもちろん、 チャットやドキュメントツールも含めて整備する AI が最大限活躍できる“土"を育てる 

©2024 Kyash Inc. 26 AIで浮いた時間は、 “盆栽" に使う A
 I
 で
 浮 い た 時 間 で
 何 を す る ？
 日 々 触 れ 育 て
 深 き 根 を 張 る
 「盆栽のように毎日触り少しずつ育 てて、複利で効果が出るチームの資 産にしていくのがよい」 の意 

©2024 Kyash Inc. ©2024 Kyash Inc. 3. 問い 27 27 

©2024 Kyash Inc. 28 AIとの開発に慣れてきた先に起きがちなこと ● 深く考えるよりも作ってしまうという選択肢を取りやすくなる ○ シュッと作れてしまう中毒性がある ○ ミーティング中に出てきた話を、ミーティング中に依頼して終わらせるといった動きもできうる ● いわゆるユーザーが本質的に求めているものを追求せずリリースを繰り返す“ビルドトラップ"にハ マりやすくなる可能性 ● 「なぜ作るか」 といった“問い"の力を今まで以上に意識し、身に染み込ませる必要がある 何でもすぐ作ってしまいたくなる問題 ﾀﾉｼｲ! 

©2024 Kyash Inc. 29 “問い"の底上げは、ユーザーを理解し自分で考えぬくこと ● ニンゲンはすぐにバイアスにかかってしまう ○ AI は時を加速させてくれるため、使い手は全能感を得やすい ○ AIの出力にユーザー理解や自分の思考が誘導されないようにすること ● 情報収集ではAIをフルに活用し、浮いた時間を思考と問い、意思決定にあてる ○ ユーザーの理解、本質的に何が必要なのかの整理に時間を使うこと ○ 目的不確実性の解消により集中する ○ そのためにプロダクトマネジメントの“学習”にあてるのもよい ● これが巷で言われる「AIを活用してニンゲンにしかできない“創造的な仕事”に集中する」ということ 

©2024 Kyash Inc. 30 たとえば、 改善の意義自体を“問う" ● 「この画面にこういう検索条件をつけてほしいです」 と言われたらどう考えるか？ ○ 「Claude でシュッとできちゃうな」 とも思ってしまうが、 その検索で何をしたいのか、何が課題なのかをき ちんと理解することが大事 ○ 理解できたら、検索条件の追加という解決策が適切なのかを考える ● AI 関係なく、頭を “懐疑モード"に切り替えられるようにしておく ○ ガンガンやっていくスタンスも大事だが、 課題を理解し、理想を描いて、 解決を考える というステップは すっ飛ばしてはいけない 「それなんで必要なんでしたっけ？」 ｿﾓｿﾓ! 

©2024 Kyash Inc. 31 たとえば、 AIのアウトプットに “問う" ● AI のアウトプットをいったん疑ってみる ○ AI は口が達者で、気がまわり、それっぽいことを言ってくるため説得力がある ○ だからこそ、対ニンゲン以上に懐疑的なスタンスでレビューするほうがよい ● (今はまだ) ちゃんと理解できるまで聞く ○ AI のよいところは、何を言っても怒らないし付き合ってくれるところ ○ わからないことを自覚し、わかったふりをせずちゃんと理解できるまで聞く癖をつける ■ このスタンスは、実はAI関係なくニンゲンの同僚氏から学んだこと ● ref: https://konifar-zatsu.hatenadiary.jp/entry/2025/09/12/191133 (自分が思考誘導されているんじゃないか...？) ﾀﾞﾏｻﾚﾅｲ! 

©2024 Kyash Inc. 32 前提を“問う" ● 「これは AI にはできない」 という思い込みを捨てる ○ 細かいこと言わなくてもやらせてみたらできることが本当に増えた ○ 「これはできないだろう」、 「自分がやったほうが早い」 という思い込みを疑ってみること ● 「今のプロセスのままが最適なのか」 を考えてみる ○ AI が加速していくことで、今まで ニンゲン に最適化されてきたさまざまなプロセスがマッチしなくなる ○ たとえば Git のバージョン管理や Pull Requestでのレビュー、 ユニットテストでのQA など、 これまでと 同じやり方が最適なのかを立ち止まって考えてみること ○ その際、 新しい概念やプロセスも AI と対話しながら見出していくのがよい 

©2024 Kyash Inc. 33 AIで浮いた時間は、 “問い" に使う A
 I
 で
 浮 い た 時 間 で
 何 を す る ？
 問
 い
 を
 磨
 い
 て
 答
 え 導
 く
 「課題を理解し、何が必要かを問うステップ を飛ばさないこと。 実現のハードルが劇的 に下がったからこそ、AIに対して問う力を つけることが大事」 の意 

©2024 Kyash Inc. ©2024 Kyash Inc. 4. 禅 34 34 

©2024 Kyash Inc. 35 生産力が上がった先に何をするか ● 「学習」と「問い」に時間をあてていった先に、結局AIでニンゲンは“暇”になれるのか ● 生産力が2倍になったら、3倍を目指してさらに“適応"していくのか ○ これ以上生産力を上げてどうするのか ○ それで我々やユーザーは本当に幸せになれるのか ● AIで浮いた時間を「何もしない」という選択肢はないのか 1人あたりの生産力が2倍になったら？ 

©2024 Kyash Inc. 36 組織として勢いをセーブすることは、おそらく当面ない ● 生産力が2倍になっても、「じゃあ週休4日にしますか」ということにはならない ○ 1980年代に週休2日が当たり前になった時のような世の中の変化はいつかは起きるかもしれない ● 専門職のプレイヤーとしては、 とにかくどう適応し続けるかを楽しんで考えていくほうがいい ○ 組織の方針として決める話であり、 個々人でどうこう言っても仕方がない ○ 手段と目的が入れ替わってしまっているように感じるかもしれないが、 意識的に手段を目的化して取り組む べきレベルの変化と捉えている ﾎｼｲﾈ! 

©2024 Kyash Inc. 37 わかるけどしんどい不安 ● 「今が一番楽しい」 という人もいる ○ 「こうするのがいいけどめんどくさいな」 がすぐに実現できる ○ 自分の能力が拡張されているような感覚の楽しさ ● 「なんとなく不安だ」 という人もいる ○ とにかく動きが早い。 1〜2週間離れるだけで浦島太郎状態になるような感覚 ○ 仕事が奪われる不安というよりも、変化についていけるかの不安。 FOMO (Fear Of Missing Out) ○ 「AIに何かを依頼していないともったいない」 という新しい焦りのような感覚を持つ人もいる ｺﾜｲﾈ! 

©2024 Kyash Inc. 38 加速しすぎに対しては“禅"のような気持ちでバランスをとる ● 変化が早いからこそ、 Tipsレベルは後からキャッチアップできる ○ 日々触りアンテナは張りつつ、 過度に焦りすぎる必要はない ● 余白のないほどの忙しさからクリエイティブな発想は生まれない ○ AI関係なく新しいことにチャレンジする時間にあててもいいかもしれない ● AIの出力結果を先に見るのではなく、自分の脳を経て出力するプロセスも大事 ○ ブログ記事や登壇資料、候補者へのスカウト文の作成あたりは特にそう ■ 思考の速度を下げて考えていく中で気づくこともたくさんある ○ まだこのプロセスをAIに渡しすぎてはいけないような感覚がある ■ AIと対話していくのはよいが、タイミングや範囲、役割を明確に意識しておくこと ■ 思考を外注しすぎない。 ニンゲンがどこで価値を出し、 何をすべきかを自問する 

©2024 Kyash Inc. 39 AIで浮いた時間は、 “禅" に使う A
 I
 で
 浮 い た 時 間 で
 何 を す る ？
 余
 白
 味
 わ い
 心 を
 磨
 く
 「浮いた時間は、生産力を上げる以外のことに使 い、自分の心と感性を磨いていくことで、長期的 に見れば生産力にもよい影響を与える」 の意 

©2024 Kyash Inc. ©2024 Kyash Inc. まとめ 40 40 

©2024 Kyash Inc. 41 まとめ 1. 学び深めて AIと歩む 
 2. 日々触れ育て 深き 根を張る
 3. 問いを磨いて 答え導く 
 4. 余白味わい 心を磨く
 実は根っこの部分では新しいことはない。 AIによって顕在化が加速しただけで、今までと本質的な課題や取り組み方は変わらない。 専門職が学び続けるのは当たり前だし、ビルドトラップにハマらないようにするのは今も昔も一緒。 適応しながら“愚直”にやっていくしかない ―― プロとして――― 

©2024 Kyash Inc. “ ” 42 これらの下の句はAIが考えたでしょうか？ AIだとしたら、AIが考えるべきだったんでしょうか？ さいごに 

©2024 Kyash Inc. さいごに もしかしたら、そこにこそ「何をする？」の
 本当の答えがあるのかもしれません
 43 

©2024 Kyash Inc. エンドロール 44 監督 ： konifar 助監督 ： ChatGPT 脚本 ： konifar 構成補佐 ： ChatGPT 短歌監修 ： ChatGPT 短歌著作 ： konifar 編集 ： ChatGPT 資料協力・リサーチ ： Grok / Gemini 技術顧問 ： Claude Code / Codex ワーキングメモリ提供 ： konifar 最終意思決定 ： konifar 最終責任 ： konifar Produced by Human Decision & Responsibility 

©2024 Kyash Inc. エンドロール 45 監督 ： konifar 助監督 ： ChatGPT 脚本 ： konifar 構成補佐 ： ChatGPT 短歌監修 ： ChatGPT 短歌著作 ： konifar 編集 ： ChatGPT 資料協力・リサーチ ： Grok / Gemini 技術顧問 ： Claude Code / Codex ワーキングメモリ提供 ： konifar 最終意思決定 ： konifar 最終責任 ： konifar Produced by Human Decision & Responsibility 「より “盆栽" のメタ ファーがわかりやすい 句を考えてみました」 「デブサミにマッチした開 発者寄りの内容にアップ デートするのがポイントで す」 「表記の揺れ、 タイポを チェックしました」 「@◯◯さんのポストを 収集してまとめます」 「“学習"のパートが長い というのは、導入の役 割を考えると適切と言 えます」 「最終的に提案された内容を判断して決定し、 内容に責任を持っているのは監督 (ニンゲン)」 

©2024 Kyash Inc. ©2024 Kyash Inc. 46 46 ありがとうございました！ 

©2024 Kyash Inc. 47 参考記事・資料・本 ● AIによる開発高速化で作り出した時間は新機能開発でなくユーザー理解に使おう : shibayu=san ○ https://blog.shibayu36.org/entry/2025/07/07/100000 ○ AIで高速化してできた余白をどう使っていくべきかという雑談からshibayuさんの考えをまとめたとても素晴らしい記事 ○ 「どこに時間を使うべきか強く意識しておきたい」というビルドトラップ防止にもつながる言葉が特によい ● AI時代のソフトウェア開発を考える（2025/11版） : t-wada=san ○ https://2025.agilejapan.jp/wp-content/uploads/2025/11/1114_1000-1050_キーノート_agentic-software-engineering-agile-japan-202511.pdf ○ AIとの開発の現在地から本質的な課題の理解、スタンスなどの話をまとめたとても素晴らしい資料 ○ 「問題の構造は変わらず、圧倒的に顕在化が早まっただけ」、伴走と委託のモードといった整理が特に秀逸 ● エンジニアリングマネージャーのロードマップ エンジニアリングマネジメントの4次元と生成AI時代の戦い方 : hirokidaichi=san ○ https://hirokidaichi.github.io/presentation/emconf.html#68 ○ EMにかぎらずエンジニアがどういうスタンスでAIと付き合っていけばよいかがまとまっている素晴らしい資料 ○ 「すべてのエンジニアは、AIをメンバーに持つエンジニアリングマネージャになる」 の言葉が特に秀逸 ● プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける : Melissa Perri (著) / ryuzee=san (翻訳) ○ https://www.amazon.co.jp/dp/4873119251 ○ ビルドトラップにハマらず顧客に価値を届けるプロダクトマネジメントが学べる素晴らしい本 ● 今はまだ生成AIに自分の文章を書かせたくない : songmu=san ○ https://blog.song.mu/entry/cautious-attitude-toward-generative-ai ○ 生成AIで文章を書くことはできるが、そこはあえて使わないという現時点でのスタンスをとった素晴らしい記事 ○ 「人類が自分を見失わないこと、人生を楽しむこと、未来の可能性を信じる事、そういった根源的な哲学が大事」とい締めが特に秀逸 ｱﾘｶﾞﾄｳ!