若手エンジニアがAIとどう向き合っているか

技育CAMPアカデミア

Transcript

1. © 2015 - 2026 Nowcast Inc. 技育CAMPアカデミア 若⼿エンジニアがAIとどう向き合っているか 株式会社Finatext 城⼾透⾺ 1
2. © 2015 - 2026 Nowcast Inc. ⾃⼰紹介 2 名前: 城戸透馬 所属: Finatext (Brokerage) 入社: 2025年 趣味: サッカー その他: ピクニックにはまっています
3. © 2015 - 2026 Nowcast Inc. AI使っていますか？ 使っていたら教えてください • ツール • ⽉課⾦額など • おすすめなど 3
4. © 2015 - 2026 Nowcast Inc. ⽬次 01 エンジニアの仕事とAI 02 AIを使って学習を加速 03 深掘り実践（Docker） 04 コーディングエージェントの実装について 05 ⼀年間を振り返り 4
5. © 2015 - 2026 Nowcast Inc. エンジニアの仕事とAI 5
6. © 2015 - 2026 Nowcast Inc. エンジニアの仕事とは何か 本質 技術を使って現実の課題を解決し、価値を⽣み出すこと コードを書くことは「⼿段」にすぎない エンジニアの仕事の実体は、課題発⾒から運⽤まで「5つのフェーズ」を繰り返すことにある 6
7. © 2015 - 2026 Nowcast Inc. エンジニアの仕事サイクル（5フェーズ） フェーズ 問い 内容 ① 課題発⾒‧要件定義 What / Why 何が問題で、何を解決するためにどんなシステムが必要かを決める ② 設計‧アーキテクチャ How（構造） 要件を満たす技術‧データ構造‧システム構成を描く ③ 実装‧コーディング How（⼿段） 設計に従い、実際に動くプログラムを記述する ④ テスト‧検証 Check 要件通りに安全に動くか（バグ‧脆弱性なく）確認する ⑤ 運⽤‧保守 Run システムを安定稼働させ、変化に合わせて改修し続ける 7
8. © 2015 - 2026 Nowcast Inc. AIコーディングエージェントの台頭 ⾃律的に動く「コード作業エージェント」 コードを 探す‧理解する 既存コードベースを⾃律的に 調査‧把握する 実装する 要件に基づきコードを ⾃動⽣成‧修正する git操作まで コミット‧PR作成まで ⼀貫して⾃動化する 8
9. © 2015 - 2026 Nowcast Inc. AIは全フェーズを⽀援する フェーズ AIの役割 ① 課題発⾒‧要件定義 調査‧要約‧案出し ② 設計‧アーキテクチャ 設計の書き出し ③ 実装‧コーディング コードの書き出し ④ テスト‧検証 要約‧指摘 ⑤ 運⽤‧保守 エラー調査 9
10. © 2015 - 2026 Nowcast Inc. AIによってエンジニアって不要になっていくと思いますか？ 10
11. © 2015 - 2026 Nowcast Inc. 技術的な知識はより求められるようになった 誰でもAIを使って開発するようになった 元々開発していた⼈の速度も上がった ▼ 成果物が増え、技術的な知識を元に判断する回数が増えた 「判断の質」がエンジニアに求められる 11
12. © 2015 - 2026 Nowcast Inc. ⼀⽅、判断の⾃動化は進むが…（ハーネスエンジニアリング） 全く新しいシステムではAI同⼠が相互監視し、判断の⼀部は⾃動化するシステムが作れるかもしれない ✓ AIが相互にレビューする ✓ 開発と並⾏してAIがコンテキスト整備ができる ✓ AIが最終成果物、ログなどを監視 AIの判断の階層‧クオリティが上がることで、⼈間の判断の回数を減らせる 12
13. © 2015 - 2026 Nowcast Inc. AIに最終的な責任は取れない ⽣成AIがいくら優秀になろうが、変わらない2つの理由 理由 ① 推論の不確実性 AIは確率的な推論を⾏う。同じ⼊⼒でも異なる出⼒が⽣じうる不確 実性を持ち、「確実な答え」を保証できない。 理由 ② 性能と透明性のトレードオフ ⾼性能なモデルほど内部の判断過程が不透明になる。「なぜその答 えを出したか」を説明できない。 責任を持って最終的な決断を下すのは、依然として⼈間の役割 13
14. © 2015 - 2026 Nowcast Inc. だからこそ、深い技術知識が問われる より深く本質的な 「技術的知識」が強く求められる AIが判断を補助する時代だからこそ、浅い理解では通⽤しない AIを使いこなす ための⼟台は、深い技術理解にある このセッションを通じて、AIと向き合うエンジニアとしての 学び⽅‧考え⽅を⼀緒に考えていきましょう 14
15. © 2015 - 2026 Nowcast Inc. AIを使って学習を加速 15
16. © 2015 - 2026 Nowcast Inc. AIが得意な5つのこと AIはエンジニアの⽇常業務の多くをカバーできる。まず何ができるかを把握しよう。 📝 ⽂書‧⾔語化 仕様の要約‧議事録整理 要件の⾔語化 💻 コーディング コード⽣成‧リファクタリ ング テスト作成 🔍 デバッグ‧調査 バグ原因の推定 ログの読み取り補助 📚 技術調査 APIの使い⽅調査 移⾏⼿順の提案 ✅ レビュー⽀援 PRレビューの観点出し リスク指摘 16
17. © 2015 - 2026 Nowcast Inc. スキルは不要になるが知識は必要 AIが得意な作業、スキルは「任せる」判断ができる。⼀⽅で、AIの出⼒を判断‧検証する⼒は引き続き⼈間に必要。 不要になりうる ✕ 仕様の要約‧議事録の整理 ✕ 暗記系の知識（CLIのオプション等） ✕ 定型的なコーディング 知識としては引き続き必要 ◦ 出⼒の正しさを判断する知識 ◦ 設計‧アーキテクチャの意思決定 ◦ ビジネス⽂脈の理解 17 ✕ 誰でも作れるアプリケーションの実装
18. © 2015 - 2026 Nowcast Inc. AIの得意を学習に活かす⽅法 AIが得意なこと（この先不要になるスキル）は、そのまま学習のツールとして使える。 📖 ⽅法 1 要約で全体像を掴む ⻑い仕様書‧ドキュメントをまず要約して もらい、全体像を把握してから詳細へ ❓ ⽅法 2 質問でピンポイントに理解する わからない箇所をクリティカルに聞ける わからない部分を質問形式で深掘りする と、集中⼒も維持しやすい ⚙ ⽅法 3 デモを作って仕組みを理解する コードベースで動きを確認することで、 概念が定着する エンジニア向き 18
19. © 2015 - 2026 Nowcast Inc. インプットする癖をつけよう 19
20. © 2015 - 2026 Nowcast Inc. 若⼿にとってインプットは最優先投資 アウトプットより先に、インプットの⼟台を作ることが若⼿エンジニアの成⻑を左右する。 若⼿はアウトプットよりインプットが重要 ⼟台がなければアウトプットの質は上がらない AIには何回でも質問できる 上司に聞くのは遠慮しちゃうけど、AIなら躊躇わなくて良い 質問形式にすると集中⼒が保ちやすい 「読む」より「対話する」⽅が理解が深まる 寄り道しまくろう 気になったことを脱線して深掘りすることが、後で繋がる知識になる 20
21. © 2015 - 2026 Nowcast Inc. 深掘り実践 Dockerをちゃんと理解する 21
22. © 2015 - 2026 Nowcast Inc. 深掘りをする上で 22
23. © 2015 - 2026 Nowcast Inc. 回答を読んで終わりにしない⸺「説明できる」まで繰り返す AIの回答を読んだだけでは「わかったつもり」になりやすい。 ⼤事なのは⾃分の⾔葉で説明できるか確かめること。それをAIに投げ返すと、間違いを直してもらえるし、次の疑問が⽣まれる。 ① AIに質問する ② 回答を読む ③ ⾃分の⾔葉でまとめてAIに投げ返す（「こういう理解であってる？」） ④ 知らない⾔葉‧ピンとこない箇所が出てくる ⑤ 新しいスレッドでその⾔葉を聞く → ① に戻る ⽬標は「読んでわかった」ではなく「⾃分の⾔葉で説明できる」 23
24. © 2015 - 2026 Nowcast Inc. 今の⾃分の知識を確認する⸺深掘りの前に「なんとなく」を棚卸し AIに聞く前に、今の⾃分の理解を整理しておく。「使える」けど「説明できない」ことが何かを意識するだけで、質問の解像度が上がる。 なんとなく知っていたこと コンテナを⽴ち上げられる アプリの依存関係をまとめられて、丸ごと削除やデプロイが可能 軽量‧⾼速である（らしい） 「使える」けど「説明できない」⸺これが深掘りを始めるサイン 24
25. © 2015 - 2026 Nowcast Inc. まずはAIにDockerについて質問 25
26. © 2015 - 2026 Nowcast Inc. AIに聞く：「Dockerの仕組みを説明してください」 「Dockerの仕組みを説明してください」 AI Dockerは「アプリの実⾏に必要なものをすべて詰め込んだ持ち運び可能な箱」を作る技術です。 重要なのが「コンテナ」と「仮想マシン（VM）」の違いで…… 💡 「VMがわからない。VMについて聞こう」 26
27. © 2015 - 2026 Nowcast Inc. VMについて質問 27
28. © 2015 - 2026 Nowcast Inc. AIに聞く：「VMの仕組みを説明してください」 「VMの仕組みを説明してください」 AI ハイパーバイザという仕組みが1台の物理コンピュータを複数の独⽴したコンピュータに⾒せかけます。 マンションの管理⼈に例えると…… 💡 「 そもそもコンピュータの基本動作がわかっていない気がする」 「Dockerって何？」 └─ VMが出てくる → 「VMって何？」 └─ ハイパーバイザが出てくる → ピンとこない └─ 「コンピュータの基本動作から教えて」 ← 立ち返る 28
29. © 2015 - 2026 Nowcast Inc. コンピュータの基本動作を質問 29
30. © 2015 - 2026 Nowcast Inc. AIに聞く：「コンピュータの基本動作を教えてください」 AI コンピュータは、メモリ上に並んだ「命令」と「値」をCPUが順番に読み取って処理しているだけです。ブラウザもゲームも、突き詰めればメモリ 上の命令の集まりにすぎません。 カーネル（OSの核）も同じで、メモリ上の命令の集まりです。ただしCPUには「特権モード」という仕組みがあり、カーネルの命令だけがハード ウェアを直接操作できます。⼀般のアプリがハードを触りたいときは、カーネルに「お願い」（システムコール）を出す必要があります。 💡 つまりこういうことかな？ メモリ（RAM） 命令と値が並んでいる場所 CPU メモリから命令を読んで処理する ハードウェア 処理結果を受けて動く （画⾯‧ディスク‧ネットワーク） アプリ カーネル 正体 メモリ上の命令の集まり メモリ上の命令の集まり 権限 ⼀般（ハードに直接触れない） 特権（ハードを直接操作できる） ハードを使いたい場合 カーネルにシステムコールで依頼 直接操作 30
31. © 2015 - 2026 Nowcast Inc. ⾃分の⾔葉でまとめてAIに投げ返す 理解を⾃分の⾔葉でまとめてAIに投げる。間違っていれば訂正してもらえるし、理解が深まれば次の問いが⽣まれる。 ⾃分 「つまり、アプリもカーネルもどちらもメモリ上の命令の集まりで、 ハードウェアを直接操作できるかどうかの権限が違うだけ、ということ？」 AI 「そのとおりです。アプリがハードを使いたいときは必ずカーネルに依頼（システムコール）する必要があります」 ✓ 理解が固まった。これでVMをもう⼀度聞く準備ができた。 31
32. © 2015 - 2026 Nowcast Inc. VMの仕組みをもう⼀度質問 32
33. © 2015 - 2026 Nowcast Inc. 同じスレッドで続けて：「この知識をもとにVMを解説してください」 「この知識をもとに、VMの仕組みを解説してください」 AI 通常は1台のマシンにカーネルが1つ常駐しています。 VMを使うと、ホストのカーネルに加えて、ゲストOSのカーネルもメモリ上にロードされます。 ハイパーバイザというソフトウェアが、この2つのカーネルの間に⼊って命令を中継します。中継の中⾝は主に2つです。 ‧メモリ空間の割り当て：ゲストが「0番地」と思っているアドレスを、物理メモリの別の場所に対応させる ‧命令の変換：ゲストがハードウェアに直接触ろうとすると、その命令をハイパーバイザがキャッチして代わりに処理する … 💡 つまりこういうことかな？ 1. VMを⽴ち上げるとハイパーバイザ、ゲストカーネル（VMのOS）がメモリ上にのる 2. ゲストカーネルの命令を ハイパーバイザがキャッチ‧変換 3. ハイパーバイザ → ホストカーネルに中継 → 物理HWを操作 33
34. © 2015 - 2026 Nowcast Inc. ⾃分の⾔葉でまとめてAIに投げ返す 「つまり、VMを⽴ち上げるとメモリ上にハイパーバイザとゲストカーネルの命令が追加される。 ゲストカーネルにはハードを直接動かす権限はなくて、 ハイパーバイザが中継してホストカーネルに命令を出している、ということ？」 AI 「正確です。加えてメモリアドレスの変換もハイパーバイザが担っています」 ✓ 理解が固まった。これでDockerをもう⼀度聞く準備ができた。 34
35. © 2015 - 2026 Nowcast Inc. ようやくDockerまで戻ってきた 35
36. © 2015 - 2026 Nowcast Inc. 同じスレッドで続けて：「この知識をもとにDockerを解説してください」 「この知識をもとに、Dockerの仕組みを解説してください」 AI VMが「別のカーネルをメモリにまるごとロードして、ハイパーバイザが命令を中継する」仕組みだとすると、DockerはそのゲストOSのカーネルを 丸ごと省略したものです。 コンテナ内のアプリが出すシステムコールは、ホストOSのカーネルにそのまま届きます。ただしカーネルは「この命令はコンテナAからのものだ」 と識別し、⾒せていいファイルやメモリ領域だけを返します。 この隔離を実現しているのが、Linuxカーネルの2つの機能です。 ‧Namespace：プロセス‧ネットワーク‧ファイルシステムなど、⾒える世界をコンテナごとに分離する ‧cgroups：CPU‧メモリなど、使えるリソースの上限をコンテナごとに設定する 💡 つまりこういうことかな？ VM：ゲストカーネルを複製 ゲストカーネル（重い） ハイパーバイザ / ホストカーネル Docker：ホストカーネルを共有 Namespace / cgroups で隔離 ホストカーネル（1つで済む） 36
37. © 2015 - 2026 Nowcast Inc. ⾃分の⾔葉でまとめてAIに投げ返す ⾃分 「Dockerはゲストカーネルを持たず、ホストカーネルが直接Namespaceとcgroupsで コンテナのプロセスを隔離している。VMよりも軽いのはゲストカーネルのロードが不要だから、ということ？」 AI 「そのとおりです。ゲストカーネルがない分、命令変換のオーバーヘッドもなく起動も速い」 ✓ Dockerをちゃんと説明できるようになった 37
38. © 2015 - 2026 Nowcast Inc. 理解の構造を整理しよう 38
39. © 2015 - 2026 Nowcast Inc. 疑問を連鎖させた結果⸺知識が⽊構造になった 「Dockerって何？」という問いから始め、⾃分の⾔葉でまとめては投げ返すループを繰り返した結果、コンピュータ基礎まで到達できた。 Docker ├─ コンテナの仕組み │ ├─ VMとの比較 │ │ ├─ コンピュータの基本：メモリ上の命令を CPUが処理するだけ │ │ │ └─ カーネルも命令の一つ（特権付き） │ │ └─ VMはゲスト・ホスト2つのカーネルをハイパーバイザが中継 │ │ └─ メモリ空間の割り当て・命令の変換 │ └─ Namespace / cgroups で隔離 └─ （次の深掘り）Docker Engine / Docker Compose このハードウェアの知識は、クラウドを理解しようとした時にも使える 39
40. © 2015 - 2026 Nowcast Inc. AIを使えば「なんとなく」から「ちゃんと理解」まで⾃⾛できる 「読んでわかった気」で終わらず、⾃分の⾔葉で説明できるまで繰り返す。AIはその確認相⼿になってくれる。 ① AIに質問する ② 回答を読む ③ ⾃分の⾔葉でまとめてAIに投げ返す ④ 知らない⾔葉‧ピンとこない箇所が出てくる ⑤ 新しいスレッドでその⾔葉を聞く → ① に戻る AIは答えを出すだけでなく、「理解の確認相⼿」として使うのが本質的な使い⽅ 40
41. © 2015 - 2026 Nowcast Inc. コーディングエージェントの実装 コンテキストエンジニアリングのために 41
42. © 2015 - 2026 Nowcast Inc. AIモデルはAPIサーバに過ぎない Claude‧GPT‧Geminiなどのモデルは、外部APIとして独⽴している。エージェントはそのAPIを呼び出すクライアントにすぎない。 ローカルで起動するコーディングエージェント （Claude Code / Cursor 等） リクエスト POST /v1/messages { "system": "...", "messages": [...], "tools": [...] } Model API （独⽴したサーバ） リクエスト → ← レスポンス レスポンス { "content": "...", // テキスト返答 "type": "tool_use", // またはツール呼び出し指⽰ "name": "read_file", "input": { "path": "src/main.go" } } エージェントはモデルを「内蔵」していない。APIを「叩く」クライアントにすぎない 42
43. © 2015 - 2026 Nowcast Inc. モデルは記憶を持たない⸺毎回「全履歴」を送る モデルAPIはステートレスだ。会話を続ける場合、エージェント側が会話履歴をすべてappendして毎回送る。 ターン1 リクエスト messages: [ { role: "user", content: "ファイル⼀覧を⾒せて" } ] ターン2 リクエスト（前の履歴も追 加して送る） messages: [ { role: "user", content: "ファイル⼀覧を⾒せて" }, { role: "assistant", content: "ls を実⾏します" }, { role: "tool", content: "（ls の実⾏結果）" }, { role: "user", content: "src/ の中⾝も⾒せて" } ] コンテキストウィンドウ（上限あり） システムプロンプト ツール定義 会話履歴（ターン1） 会話履歴（ターン2） 会話履歴（ターン3） 残り容量 → 減っていく… 会話が⻑くなるほどリクエストが⼤きくなる。「Claude Codeが指⽰を忘れる」のはコンテキストが溢れているから。 会話履歴はモデルではなく「エージェント側（クライアント）」が管理する 43
44. © 2015 - 2026 Nowcast Inc. システムプロンプト：毎回送られる「前提の指⽰書」 システムプロンプトは会話の最初に設定する前提の指⽰書だ。ユーザーの発⾔より先に読み込まれ、モデルの振る舞いを規定する。 APIリクエストの構造 { "system": "あなたはコーディングエージェントです。以下のツールを 使って...", "messages": [ { "role": "user", "content": "このバグを直して" }, ... ], "tools": [ ... ] } カテゴリ 内容例 役割定義 「あなたはコードを読み書きできるエージェントで す」 ツール⼀覧 使えるツールの名前‧説明‧引数（後のスライドで詳 述） ⾏動指針 「コードを書く前に必ずファイルを読め」「確認なし に削除するな」 出⼒形式 「ツール呼び出しはJSON形式で」「⽇本語で回答せ よ」 Claude Code の実際のシステムプロンプトは数万⽂字に及ぶ。エージェントの「個性」や「安全ルール」はここに書かれている。 システムプロンプトは「会話の⼟台」⸺毎回のAPIコールで必ず送られる 44
45. © 2015 - 2026 Nowcast Inc. ツールとは何か：モデルが「使える道具」の⼀覧 コーディングエージェントがファイルを読んだりコマンドを実⾏できるのは、ツール（関数）を呼び出す仕組みがあるからだ。 ツール名 役割 使⽤例 Glob / file_search ファイルの検索（パターンマッチ） 「*.go のファイルを探して」 Read / read_file ファイルの内容を読み込む 「src/main.go を読んで」 Write / write_file ファイルを新規作成‧上書き 「新しいファイルを作成して」 Edit / edit_file ファイルの⼀部を差し替え 「この関数の実装を修正して」 Bash / run_command シェルコマンドを実⾏する 「go build でビルドして確認して」 Grep / search_in_file ファイル内のキーワード検索 「"getUser" を使っている箇所を探して」 モデルはツールを「実⾏」するのではなく、「どれを使うか指⽰」するだけ⸺実⾏はクライアント側 45
46. © 2015 - 2026 Nowcast Inc. ツール呼び出しの流れ：「判断」と「実⾏」は分離している エージェントがファイルを読む場合、「どのツールを使うか決めるフェーズ」と「実際に実⾏するフェーズ」は分離している。 ① リクエスト送信 ツール定義⼀覧を含む エージェントがAPIに リクエストを送る ② モデルが判断 推論フェーズ 「このタスクには read_fileが必要だ」 ③ ツール指⽰を返却 レスポンス { "tool": "read_file", "args": { "path": "..." } } ④ 実際に実⾏ クライアント側（エージェント） エージェントのコードが read_fileを本当に実⾏する ⑤ 結果を追記して再呼び出し messages に追加 実⾏結果をmessagesに appendしてAPIを再呼び出 し モデルはファイルを読んでいない⸺「読め」と指⽰するだけ。実⾏するのはエージェントのコード 46
47. © 2015 - 2026 Nowcast Inc. ReActパターン：Reasoning + Acting のループ コーディングエージェントの多くは「ReActパターン」という設計に基づく。考える→⾏動する→観察する を繰り返すループだ。 Reason （考える） Act （⾏動する） Observe （観察する） ループ ループの詳細 Reason モデルが現在の状況を考え 「次に何をすべきか」を判断する Act ツールを呼び出す （read_file / bash 等） Observe ツールの実⾏結果が messagesに追加される 判定 ⽬標達成？ Yes→終了 No →Reason へ このループが「⾃律的に⾒える」動きの正体。1回のAPIコールではなく何⼗回もループを回している 47
48. © 2015 - 2026 Nowcast Inc. ループの具体例：「このバグを直して」⼀⾔で何が起きているか 「src/main.go のエラーを直して」という指⽰に対して、エージェントがReactループをどう回しているかを追ってみる。 ループ1 Reason まずエラーの内容を確認しよう Act Bash("go build ./...") Observe コンパイルエラーのメッセージを受け 取る ループ2 Reason エラー箇所のコードを読もう Act Read("src/main.go") Observe ファイル内容を受け取る ループ3 Reason 型ミスを発⾒。Editで修正しよう Act Edit("src/main.go", old="int64", new="string") Observe 編集成功の確認 ループ4 Reason 再ビルドして確認しよう Act Bash("go build ./...") Observe エラーなし → ⽬標達成 → 終了 「1つの指⽰」に対して何⼗回もAPIを叩くのがコーディングエージェントの実態 48
49. © 2015 - 2026 Nowcast Inc. コンテキスト管理をしよう Reactループを何⼗回も回すと、会話履歴‧ファイル内容‧ツール結果がどんどん積み上がる。 コンテキストが溢れると、コストもかかるし、精度も落ちる。 原因 問題 対策 ⼤きなファイルを丸ごと読み込む コンテキストが⼀気に消費される 必要な⾏だけ読む（offset/limit） ⻑い会話を1セッションで続ける 古い指⽰をモデルが忘れる 定期的に /clear でリセット 無関係なツール結果が残る ノイズになって精度が落ちる 要約して圧縮する システムプロンプトが肥⼤化 コアの指⽰が埋もれる 不要なルールを削る 良いコンテキスト管理の設計観点 必要な情報だけを渡す 1会話 = 1タスク に区切る 重要な前提はシステムプロンプトへ 完了タスクはリセットして始める 49
50. © 2015 - 2026 Nowcast Inc. ⼀年間の振り返り 50
51. © 2015 - 2026 Nowcast Inc. 新卒1年⽬でやった仕事の幅 インフラ（AWS） ネットワークの更新 ALBの設定変更 コンピューティングの更新 インフラロジックの追加 サーバサイド実装 20個以上のリポジトリを横断して開発 API実装‧バグ修正‧機能追加 新規プロジェクトの要件整理とかも ほぼ全てのタスクでAIを使い倒した 51
52. © 2015 - 2026 Nowcast Inc. ⾊々なことが学べた⼀年だった やること ALBの セキュリティポリシー変更 （設定値を1つ変えるだけ） AIで深掘り 深掘りできたこと TLSハンドシェイクの仕組み 暗号スイートとは何か TLS1.2と1.3の違い 52 AIにより開発速度が上がったので、単純に消費するタスク量が多くなり⾊々なことに触れられた。 触れたことに対して、AIを使って効率的に深堀りして理解することができた。 例えば
53. © 2015 - 2026 Nowcast Inc. AIを使える環境はとても⼤事 制限がある企業 社内規則でAI利⽤を禁⽌‧制限 情報漏洩リスクを懸念 規制業界（⾦融‧医療）では制約が厳しい ガバナンス上の承認フローが複雑 Finatextでは AI利⽤が推奨される⽂化がある 技術‧AIへの感度が⾼い社員が多い 最新情報がSlackで常に流れてくる ⾃分で試して学べる環境がある AIを業務で⾃由に使える環境は、意識的に選ぶ必要がある 53 AIを使いこなすことが、エンジニアとしての競争⼒になる AIを使いこなすためには、とにかく使うこと
54. © 2015 - 2026 Nowcast Inc. 54