トーク

── AI導入、始まりはいつも絶望

舞台はとある地方中小企業…
冴えない平社員である俺は突如社内のAI導入プロジェクトに巻き込まれ、専任担当に。
数々の障害の中「社内への生成AIの普及」という難題へあの手この手を駆使し辛くも一定の評価を得、役目を終えた…

はずだったーーーーーー

「来年度もより一層推進してもらいたい」
今年はRAGを含めたAIの民主化を遂行！？
前触れもなく新たな任務を命じられた俺の運命はーーー

トーク内容(予定)
・生成AIを活用したい！けど社内規定が…という際の取り組み方
・ソロでひたすら0→1をこなす際の耐え抜き方
・ローコードプラットフォームである「Dify(ディファイ)」をセルフホストで社内環境に導入する際の勘所

※去年TechRAMENで発表された”「わが社にAIを入れるぞ！」とある地方中小企業の現在地”の続編にあたりますが、単体でも楽しめます

富良野の IT コミュニティ FuraIT には Arduino 部と名付けられた，電子工作を中心としたものづくりを追求する部活動が存在します．これまで，オンラインもくもく会では教材をなぞる形で，センサーをとりあえず使ってみて，動くものをつくって暮らしてきました．
　
最近，ある程度やりきってきたこともあり，入門では出会わない不具合にぶち当たり，これまでの教材を見ても解決せず，どうにも前に進まないことも散見されるようになってきました．そこで，電子回路の基礎に立ち返り，アナログポートの読み出しにおける注意や，基礎的な電気回路における理論等を勉強する機会を作ってはどうかと考え，工業高校教諭経験のある私が授業する方向で検討中です．
　
本発表では，センサーが出力する電圧をマイコン側で正しく受けるために気をつける，出力インピーダンスと入力インピーダンスについての理解を進める授業をおこないます．

あるレガシーな組織から、あるECサービスが 2020年12月 に公開されました。
このサービスは、Webアプリケーションとして開発されましたが、スマートフォンアプリからも利用されるようになりました。
現在ではアクティブユーザー数が27万名を超え、全道の多くの方々に利用されています。

そこから四年。

機能追加、メンバーの変遷、Vue3へのアップグレード、多くの歴史が刻まれています。
気がつくと、 Core Web Vitals の値が赤く輝いています。
そう、今こそ改善のとき。

このセッションでは、レガシー企業で産み出されたサービスを地道に改善した体験をお話しします。
この中で、何が問題になったか、改善の順番をどう考えたか、どのように改善を進めたか、といったことも具体的にお話ししていきます。

「ちょっとした技術記事をQiitaやZennやブログに投稿するぐらいなら頑張ればできるけど、技術同人誌を書くのってとてつもなくハードル高くない？」と、思っている方、結構大勢いると思います。かくいう私もその一人でした。

しかし先日、「技術同人誌を書いて技術書典に出す」という実績を解除してみたくなり、見切り発車で書き始めてなんとか電子書籍として頒布するところまでたどり着きました。
ということで、その経緯や、実際に書いてみて感じたことをお話します。

下記のようなトピックでお話する予定です。

• 需要がありそうな内容じゃなくて良い。自分が書きたいものを書こう
• 執筆にはRe:VIEWを使おう（ここがメインかも）
• 紙で出そうとすると準備が大変そう。PDFで配ろう
• 体裁や構成は他の人の同人誌を参考にしよう

こんな人におすすめ

• 技術同人誌の執筆をゆるく始めてみたい人

生成AIアプリについて「AIがアクセス禁止情報まで見てない？」と不安を感じませんか？ RAGを使うAIチャットボットが、社外秘や個人情報から回答を生成すると重大なセキュリティリスクです。
従来のアクセス制御ではAI時代の複雑なデータ管理が困難になります。

本セッションではGoogleも採用するReBAC（Relationship-Based Access Control）を紹介します。「関係性」で制御するReBACは、B2B/B2C SaaSや社内ツールに最適です。
例えば、HRプラットフォームでAIが承認済み文書のみ表示、資産管理アプリでユーザーの銀行データへ安全にアクセス、社員が自身のCRMデータにアクセス権に基づき分析する、といったきめ細やかなデータアクセス制御を実現します。
RBAC/ABACと比較し、ReBACがなぜAI時代にフィットするのかを分かりやすく解説します。

最近では生成AI・LLM API を活用した機能が増えています。

これらの API は非常に強力ですが、一般的にAPIレイテンシーが大きいです。 それらを使った機能やアプリケーションを提供する場合、ユーザーの待ち時間は当然長くなります。
ユーザーの待ち時間は、ユーザー体験に直結する重要な観点です。 この課題を緩和するために vLLMなどの推論高速化手法は日進月歩で生まれています。
しかし、このようなモデル開発者視点での待ち時間を軽減させるための手法は数多く見かける一方で、それを使ったアプリケーション開発者視点での手法はあまり見かけません。

そこで本セッションでは、アプリケーション開発者視点からユーザーの待ち時間を短くするためのシステム設計のベストプラクティスを紹介します。
ユーザーの待ち時間の最適化という視点から、生成AI時代に求められるユーザー体験のあり方を考察します。

深夜の静寂。ディスプレイの光だけが、顔を照らす。
以前に自分が書いたコードが、まるで他人の書いた暗号のように見える。
「ここを直したら、どこが壊れる…?」
震える指でコードを書き換え、動作確認を繰り返す。時間は溶け、自信は削られていく。

「単体テストを書く時間さえあれば…」
いつからかそれが僕の口癖になっていた。

でもある日、ふと気づいたんだ。
テストがないから、この恐怖が生まれる。テストがないから、この無駄な時間が生まれる。

…逆だったんだ、と。

このセッションでは、テストに守られた安心で高い生産性を誇る開発体験を無理なく獲得するための、明日からでも始められる3つの動機づけを皆さんに提案します。
将来、テストなしでどうやって開発してたんだろう、と思ってもらえるようになればうれしいです。

テストはコストじゃない。未来のあなたを、恐怖から解放するための翼なんだ。

深夜の静寂。ディスプレイの光だけが、顔を照らす。
以前に自分が書いたコードが、まるで他人の書いた暗号のように見える。
「ここを直したら、どこが壊れる…?」
震える指でコードを書き換え、動作確認を繰り返す。時間は溶け、自信は削られていく。

「単体テストを書く時間さえあれば…」
いつからかそれが僕の口癖になっていた。

でもある日、ふと気づいたんだ。
テストがないから、この恐怖が生まれる。テストがないから、この無駄な時間が生まれる。

…逆だったんだ、と。

このセッションでは、テストに守られた安心で高い生産性を誇る開発体験を無理なく獲得するための、明日からでも始められる3つの動機づけを皆さんに提案します。
将来、テストなしでどうやって開発してたんだろう、と思ってもらえるようになればうれしいです。

テストはコストじゃない。未来のあなたを、恐怖から解放するための翼なんだ。

Agentic AI の登場によって、私たち開発者の働き方は大きく変わっていこうとしています。
Cline や Roo Code、Claude Code のような Agentic AI を使うことで爆速で価値を提供できる業務もあれば、開発者の行う仕事の中にはまだまだ AI フレンドリーではない開発業務もたくさんあります。

セキュリティはどうでしょうか。
例えば、開発ライフサイクルの終盤にラスボスのように現れる、あの「脆弱性診断」というやつは・・・

この LT では、この半年間に仲間たちと Agentic AI による脆弱性診断の実現に向けて試したことや、そこで得られた知見について共有します。

アプリケーションを提供する事業会社において、セキュリティ面で考慮しなければいけないことは多岐に渡ります。
一方でデリバリーのスピードや予算、リソース面とセキュリティのバランスを取ることは非常に困難な意思決定の連続であり、時に品質やセキュリティ、アクセシビリティなどは非機能要件として軽視されることもあります。

こうした課題への打開策として昨今では「文化の醸成」といった言葉がよく語られますが、それはどのようにして実現できるのでしょうか。
本トークでは、以前に『Software Design』（技術評論社）に寄稿したシフトレフトの体験談をベースに、セキュリティと組織文化についてお話しします。

なお、タイトルは品質文化について記された名著『LEADING QUALITY』（ Ronald Cummings-John, Owais Peer, 2023）へのオマージュです。

小規模なWebサイトを構築し、ホスティングする業務はよくあると思います。
もちろん公開して終わりではなく、定期/不定期問わずに更新作業も出てくるでしょう。
急ぎのファイル差し替え、本番しかない環境、忘れらるバックアップ、色々な課題が出てきます。

このセッションでは、 AWS Amplify のホスティング機能にフォーカスし、静的サイトのデプロイや運用にまつわる作業をデモを交えながら話していきます。
特に Amazon S3 と AWS Amplify のホスティング機能を連携することで、爆速で静的サイトの公開が可能となります。
さらに、Amazon S3 の持つファイルバージョニングやライフサイクル管理により、バックアップ処理すら不要のサイト運営ができることを、お伝えします。

ぜひ皆さんも AWS Amplify で楽にホスティングをやっていきましょう！

小規模なWebサイトを構築し、ホスティングする業務はよくあると思います。
もちろん公開して終わりではなく、定期/不定期問わずに更新作業も出てくるでしょう。
急ぎのファイル差し替え、本番しかない環境、忘れらるバックアップ、色々な課題が出てきます。

このセッションでは、 AWS Amplify のホスティング機能にフォーカスし、静的サイトのデプロイや運用にまつわる作業をデモを交えながら話していきます。

• AWS Amplify を使ったホスティング
  • Amazon S3 でファイル管理を行なう方法
  • GitHub でファイル管理を行なう方法

特に「Amazon S3 でファイル管理を行なう方法」でも、既存のワークフローを大きく変えずに運用の手間を下げられる可能性があります。
ぜひ皆さんも AWS Amplify で楽にホスティングをやっていきましょう！

Web/iOS/Androidのマルチプラットフォームで、女性専用SNS「tipsys」を8年前、「食品表示印刷」を5年前、業務用ワイン管理アプリ「winecode」を3年前から開発運営しています。

これらはいずれも、プライベートプロダクトとして開発運営をスタートし、ユーザーの声や運用の中でUI/UXを何度も見直してきました。今回の登壇では、特に「なぜUIを変えたのか」にフォーカスし、0→1の立ち上げフェーズで見えた課題、そして運用中に直面した“変えざるを得なかった理由”をお話しします。

「tipsys」で考えたゼロスタートのSNS、「食品表示印刷」での現場ユーザーの声、「winecode」での業務効率とのせめぎ合い。それぞれのアプリが抱えた背景とUIのアップデートを、数字やスクリーンショットとともにお話します。

[技術レベル]
不要です。

LLM含め数多くの生成AIとそれらを活用したAIエージェントの進歩によって、とりわけITエンジニアにとってのソフトウェア開発の難易度はより下がりました。
環境構築から実際の開発、リリースまでその多くを生成AIに任せられるようになったからこそ、とりあえず作ってみてダメだったら放置する、それでも温かみのある手作りのツール・ライブラリの開発ができるように。
ブラウザの拡張機能、CLI、Codemod、簡易的なスクリプトその多くをある種雑に作り放置できるようになったからこそできるようになった「いっちょやってみるか」の姿勢での開発、すなわち「どんなもんだ、いっちょ、やってみるか」＝「DIY」精神の開発についてLTします。

皆さんは普段、コーディング規約についてどこまで考えていますか？
筆者はかつてコーディング規約アンチでした。

そんな中去年のtechramen24confのt_wadaさんの登壇からベースラインを作り漸進的に開発していくことの重要性を学び、同じくt_wadaさんが出演していたPodcast、「fukabori.fm - 100. A Philosophy of Software Design (1/3) w/ twada」を聞いたことで、新たな発見を得ました。

それが、コーディング規約によってコードベースの複雑性・不確実性を下げることです。
加えてコーディング規約を定めることで求められる「腹を決める」ことによる覚悟。
これらを通して見えてきた、可読性の高いコードベースの作り方とその挑戦と結果、規約によって得た副次的な効果としてVibe Codingでの活用についもトークします。

概要: 実際の開発プロジェクトで、アーキテクチャ設計に LLM を活用した事例を紹介します。
対象: アーキテクチャ設計に関心のある方・LLM を業務で活用したい方

現代の Web 開発は、迅速なリリースと柔軟な仕様変更が求められます。そのため、対話を中心として情報を共有し、詳細なドキュメント作成は後回し・最小限になりがちです。この方法にも利点があるものの、ドキュメント不足による手戻りの発生や属人化など、課題があります。
しかし LLM の台頭により、ドキュメント作成コストの考え方が変わりました。ドキュメント作成コストが低減した前提に立てば、開発プロセス全体を見直す余地があります。

本トークでは、実装に入る前のアーキテクチャ設計において、LLM を活用した事例について紹介します。LLM の具体的な活用方法、チームでの運用、そしてその効果と課題について、実践に基づいた内容をお話しします。