こんにちは！AI部の吉富です。

皆さん、社内へのAI情報発信や浸透はどのように行われていますか？
現在、ドリコムAI部では社内向けの「AIポータルサイト」を開発中です。今回は、なぜ今ポータルサイトが必要なのか、そしてAI活用推進の立場としてどのような機能を盛り込んだのかをご紹介します。

なぜ今、ポータルサイトが必要なのか

私たちはこれまでも、「AIDAY」などの社内イベントや、チャットツール上の「共有部屋」を通じて発信を行ってきました。しかし、部内での議論を通じて、AI活用をさらに加速させる上で「既存の手段では拾いきれない価値」があることが明確になりました。

1. チャットツールの「成果バイアス」と「埋もれる知見」

Slackなどのチャットツールは情報の即時性に優れていますが、運用していく中で「”成果”としてまとまっていないと投稿しづらい」という心理的なハードルが生まれていました。

• 発信する側：「うまくいったこと」は投稿できるが、試行錯誤中の「失敗」や「小さな発見」は投稿を躊躇してしまう。
• 受け取る側：完成された成果物以外に対して、どのようなリアクションを返すべきか迷うことがある。

しかし、AI開発において本当に価値があるのは、成功した結果そのものよりも、「１つの成果が出るまでの過程（失敗談、プロンプトの工夫、エラーへの対処）」にこそあります。チャットという「フロー型」のツールでは、こうした貴重な「過程の知見」が流れてしまい、後から検索して再利用することが困難でした。

2. イベント発信の「タイムラグ」

また、社内イベントでの共有も重要ですが、開催準備や時間の制約があるため、日進月歩で進化するAIのスピード感に情報の鮮度が追いつかないという課題がありました。都度しっかりとした資料を作るコストも無視できません。

結論：「過程」を「ストック」する場所を作る

そこで我々は、チャットのように流れてしまわず、かつ資料作成のような高コストもかけずに、「日々のニュースや検証の過程（プロセス）を、可能な限り”楽”にストックできる場所」として、社内ポータルサイトの構築に至りました。

開発・運用思想：徹底して「楽」を追求する

「過程」をストックするためには、投稿のハードルを極限まで下げる必要があります。そこで、開発手法はもちろんのこと、稼働後の「サイト運用」においても最大限にAIを活用し、徹底して「楽」ができることを重視しました。

1. 「開発の楽」を満たす技術選定：Agentとの親和性

実は私自身、元々はクライアントサイドのエンジニアとして開発業務に従事しており、サーバーサイドの環境構築を0から100まで独力で設計・実装した深い経験はありません。

そんな「非サーバーエンジニア」の私が今回重視したのが、AI Agentによるバイブコーディングとの親和性です。

開発プロセス自体にClaude Codeを利用し、可能な限りAI主導のコーディングに委ねるスタイルをとっています。そしてデプロイ先にはAWS Amplify（Gen 2）を採用しました。

Amplifyには amplify/data/resource.ts などにデータモデルをコードとして定義することで、DynamoDBなどのリソース構成を一括で行ってくれる機能があります。これにより、以下のフローが可能になります。

1. Agentによる定義：人間がAWSコンソールを操作するのではなく、AI Agentにデータモデルのコードを書かせる。
2. GitHub連携：生成されたコードをリポジトリにプッシュする。
3. 自動構築：Amplifyがコードを読み取り、デプロイからDB構築までを一貫して自動反映する。

この構成であれば、人間が手動でインフラを詳細設定することなく、「コードを書く（書かせる）」ことだけに集中できるため、専門的なサーバーサイドの知見が不足していてもスムーズな立ち上げが可能となりました。

2. 「運用の楽」を満たすAI機能の実装

ポータルサイトを作っても、記事を書くのが面倒で更新されなければ意味がありません。そこで、コンテンツの「生成」と「検索」にGoogleの最新モデル Gemini 3 Pro シリーズを組み込んでいます。

AIによる記事生成アシスト
通常の手動投稿に加え、AIを利用した記事作成機能を実装しました。「箇条書き」などの簡単なメモを入力するだけで、Gemini 3 Pro Previewが一瞬で記事の下書きまでを作成してくれます。

オンデマンド画像生成
記事のアイキャッチや挿入画像の準備は意外と手間がかかるものです。そこで、画像のアップロード機能に加え、Gemini 3 Pro Image Previewを活用した生成機能を搭載しました。
記事の内容や自然言語プロンプトから、その場で画像を生成して貼り付けられるため、素材探しの時間をゼロにできます。

AI検索（検討中）
現在はキーワードやタグ検索が主ですが、将来的にはサイト内の蓄積された情報をAIで検索・要約して回答する機能の実装も検討しています。

まとめ

このポータルサイト開発における最大の収穫は、開発から運用までのあらゆるフェーズで「AIに任せる」という選択肢が実用的になっていると実証できたことです。「書くのが面倒」「作るのが大変」というボトルネックをAIで解消することで、本当に価値ある「知見の中身」に集中できる環境が整いました。

そして、この環境は私たちエンジニアが「作れるもの」の範囲も劇的に広げてくれました。サーバーサイドの専門家ではない私でも、Agentと最新モデルを組み合わせることで、ここまでのシステムを短期間で構築し、運用に乗せることができています。

今後もこのポータルを通じて、「成果」だけでなく「過程」の知見が自然と集まる仕組みを磨き込み、社内のAI活用をさらに加速させていきたいと思います。

非サーバーエンジニアが挑む、社内AIポータルサイトの立ち上げはTech Inside Drecomで公開された投稿です。

技術書典とは

技術書典は、エンジニアやクリエイターが自分の技術的な知見や経験を同人誌として頒布する、技術書に特化した即売会イベントです。技術系の同人誌即売会としては最大級の規模で、多種多様なジャンルの本が一堂に会します。
オンライン頒布とオフライン会場（リアルイベント）が組み合わさっているのも特徴で、会場で実際に読者と会話しながら本を手渡せる一方で、当日足を運べない人にも通販を通じて届けることができます。
また、個人・小規模サークルでも比較的参加しやすく、初参加でも運営のガイドやバックアップ印刷所、備品の提供などが整っているため、「一度自分の本を作ってみたい」という人にとって良いチャレンジの場になっています。

参加のきっかけ

普段の業務や個人開発で触れていた「Amazon EKS」と、その基盤上で「n8n」をセルフホストする方法について、あまり公開された情報がなかったため、本にまとめてみたいと思いました。
また、『自分が作ったモノを売るイベント』を経験してみたいという思いもあり、技術書典への参加を決めました。

執筆・制作

執筆環境

原稿作成には、技術同人で広く使われているマークアップベースの執筆ツール Re:VIEW を使いました。
また、Re:VIEW向けの書籍制作テンプレートである TechBooster/ReVIEW-Template をフォークし、紙面・ページフォーマット設定やPDF出力タスクを再利用しつつ、GitHub Actionsで原稿更新後すぐにPDF生成して確認できるようにしました。

表紙作成

表紙デザインはエンジニアが技術書を作る上での大きなハードルの一つですが、最近では有償・無償を問わず優れたツールがあり、技術書ならではのシンプルな表紙でも十分通用すると思います。
ただ、注意点としては素材やフォントの著作権・ライセンスを必ず確認すること。生成AIで画像を作る場合でも、元データの取り扱いや商用利用可否が明示されたサービスを選び、引用元がある場合は本文や奥付でクレジットを入れるなど、権利者へのリスペクトを忘れないようにしましょう。
また、「ジャケ買い」という言葉もあるように、表紙デザインは読者の購買意欲に大きく影響するため、可能であればデザイナーに依頼するのも良いでしょう。

スケジュール管理

執筆用の Re:VIEW-Template リポジトリをフォークしたのが 2025 年 7 月末で、原稿の最新コミットが 10 月中旬でした。おおよそ 2.5 ヶ月間で 98 ページを書いたことになり、結果的には「ほぼ 1 日 1 ページ」くらいのペース感でした。
進め方としては、平日・週末を問わず、基本的に毎朝 1 時間を執筆時間として確保するスタイルを取りました。実際には本の内容に関する調査・検証や、慣れない表紙デザインの調整にも時間を割いていましたが、「毎日少しずつでも手を動かす」という習慣を作れたことは、執筆を最後まで続けるうえでかなり効果的だったと感じています。

入稿・印刷

技術書典はバックアップ印刷所が充実しており、私もこちらを利用させて頂きました。
紙の本の作成は初めてだったので、トンボや塗り足しの設定、表紙のカラーモードなど、慣れない点も多かったのですが、事前に紙質や色味のサンプルを取り寄せて確認したことで、無事に入稿を完了しました。

イベント当日

当日の準備

技術書典は初参加だったのですが、かんぜん手ぶらセットというほぼ備品を用意せずに設営できるサービスがあったため、本当に助かりました。
ただ、さすがに1人での参加は厳しいと思ったため、事前に2名ほどエンジニアの仲間を誘い、交代でブースを見てもらえるように調整しました。

設営

イベントの設営は初めてでしたが、隣のブースを参考にしつつ、見よう見まねで進めました。本の陳列やサンプル、ホワイトボードに書いたキャッチコピーの配置などは、実際にお客さんの動きを見ながら、開催中も少しずつ調整していきました。

実際に自分の本を売ってみて

本の内容に興味を持ってくださった方が、真剣に質問や感想を伝えてくれるケースが多く、とても刺激になりました。
また、直接のフィードバックをもらえることで、自分の知識や経験が他の人に役立っていることを実感できました。

振り返り

準備は早いに越したことはない

印刷所への入稿が早いと割引を受けられることも多いのと、余裕を持った執筆が内容の質向上につながるため、早いに越したことはないです。
ただ、例えば生成AI関連のように、技術の進化が早い分野の場合は、内容が古くなってしまうため注意が必要です。

最後まで誰の手も借りずにできるか

自分の場合は初参加でイベント会場の雰囲気も分からなかったため、手伝ってもらいましたが、隣のブースの方は1人で参加されていました。
1人参加の場合は、昼食や休憩、他のブースを見回るタイミングが難しいため、可能ならば複数人で参加するほうが良いと思いました。

技術書典で売れる本の考察

あくまでも、個人的な考察ですが、技術書典で売れる本には以下のような特徴があると感じました。

• ニッチ過ぎない
  • 技術書典イベントに参加する方は老若男女様々でした。感覚として新しい技術やツールに興味を持つ人が多いため、入門書的な内容が好まれると感じました。
• 市販本との差別化:
  • 逆に個人の経験にもとづく「誰もこんなことは市販本で書かない」感が強い本は、技術書典ならではの魅力になると思いました。
• 著者及びサークルのブランド力:
  • 継続的に良質な本を出しているサークルや、有名な著者のブースは行列ができ、売り切れも出ていました。

おわりに

技術書典は、自分の持つ技術の分野に興味を持つ多くの人々と直接交流できる貴重な機会であり、知識や経験を共有する素晴らしい場です。1つの本を作り上げる大変な面もありますが、準備をしっかり行い、周囲のサポートを得ることで、充実した経験が得られると思います。
興味がある方は、ぜひ挑戦してみてください。

技術書典19に個人で本を出してみた話はTech Inside Drecomで公開された投稿です。

なぜ今、デザイナーにAIが必要なのか

AIは『なんでもできる魔法』ではない

デザイン業務の各シーンにおけるAI活用アイデア

アイデアの壁打ち・ビジュアルイメージの視覚化

素材加工の効率化

バリエーション検討作業の効率化

AIとのコミュニケーションのコツ

1. 指示は「具体的」かつ「明確」にする

2. 「キーワード」でイメージを補強する

3. 「スタイル」や「画風」を指定する

4. 不要な要素を取り除く

まとめ：AIを「新しいパートナー」として捉える

デザイナーの業務効率化のための「AI活用アイデア」はTech Inside Drecomで公開された投稿です。

背景：長期運用タイトルを悩ませる「組み合わせ爆発」

最初の挑戦：LLMによる「総当たりシナジー評価」という夢

「新規で開発するスキルの効果をLLMに渡し、既存の全てのスキルとの連携度合いを評価させ、リスクを分析する」

立ちはだかった「2つの壁」

課題1：計算量という物理的な壁

課題2：「見つける」だけでは不十分という本質的な壁

次の一手：網羅性より「精度と速度」、そして「データ資産」へ

【活用案1】検証（QA）業務の高度化

• 類似バグの水平展開:
  あるスキルで「特定のステータス異常が効かない」という不具合が見つかった際、データベースに「類似の効果を持つスキルを全て抽出して」と問い合わせることで、同様の不具合を抱えている可能性のあるスキルを洗い出し、効率的な回帰テストに繋げます。
• 仕様変更時の影響範囲調査:
  「クリティカルダメージの計算式変更」など、ゲームの根幹に関わる仕様変更の際に、影響を受ける可能性のある全スキルを瞬時にリストアップし、テスト計画の精度を向上させます。

【活用案2】企画・バランス調整業務のデータ駆動化

• 新スキル設計の支援:
  プランナーが「“暗闇”を付与しつつ、味方の“スピード”を上げるスキルを作りたい」と考えた際、データベースを検索して「そもそも類似の効果は過去に存在するか？」「存在するなら、パラメータの相場はどのくらいか？」を即座に把握でき、パワーインフレの抑制や設計工数の削減に繋がります。
• ゲーム環境の可視化:
  データベース内の全スキルを分析し、「現在、攻撃力上昇バフを持つスキルは何種類あり、その平均値はいくつか？」といった統計情報を出力できます。これにより、キャラクターの追加やバランス調整を、客観的なデータに基づいて行うことが可能になります。

まとめ

AIは「スキルの全組み合わせ評価」の夢を見るか？―― 網羅的アプローチの挑戦と次の一手はTech Inside Drecomで公開された投稿です。

1. 事例の横展開と相談の場を創出する「AI DAY」

• 社内で利用可能なAIツールの紹介・アップデート共有
• 部署横断での具体的なAI活用事例の共有
• AI活用の個別相談・壁打ち

2. 多様なニーズに応えるためのAIツール環境

• ai and
  位置づけ： Drecom独自の課題に対応する自社開発ツール
  汎用ツールではカバーしきれない、当社特有の業務やデータに特化したAIツールです。ゲーム開発を中心とした社内プロダクト開発を支援しています。
• Gemini
  位置づけ： 全社員の基本的な生産性向上を担う汎用ツール
  Googleの高性能な生成AIです。文章作成やアイデア出しなど、あらゆるシーンでの利用を想定し、まずはAIに触れてもらうためのベースツールとして提供しています。
• Dify
  位置づけ： 現場主導でのAIアプリ開発を促進するノーコードプラットフォーム
  プログラミング知識のない非エンジニアでも、独自のAIチャットボットなどを構築できるのが特徴です。「現場の課題は現場が一番よく知っている」という考えのもと、各部署が自律的に業務効率化を進められる環境を目指して導入しました。
• n8n
  位置づけ： 既存業務プロセスへのAI組込みを加速するワークフロー自動化ツール
  AIを単体で使うだけでなく、各種SaaSと連携させて業務フロー全体を自動化するために提供しています。これにより、AI活用を一過性のものから、持続可能な業務プロセスへと昇華させることを目指します。
• その他にも
  claude code, github copilot, devin, figma make,等、開発現場からのニーズに迅速に対応し、気軽な活用テストの機会を提供できるよう心がけています。

まとめ

スペックよりも「ワクワク」を。楽しさ起点で推進する、Drecom流AIカルチャー醸成術はTech Inside Drecomで公開された投稿です。

開発の背景：データ取得の迅速化が急務だった

Slackで質問するだけ！AIデータ取得BOTの仕組み

1. 担当者がSlackで質問
   • 例：「9月の〇〇ガチャの実行人数は？」といった自然な日本語で質問します 。
2. AIが日本語をSQLに変換
   • 質問の意図をAIが解釈し、データベースへの問い合わせ言語であるSQLを自動で生成します 。
   • 例：SELECT COUNT(DISTINCT user_id) FROM ...
3. BigQueryでデータを抽出
   • 生成されたSQLをデータベース（BigQuery）に送信し、データを抽出します 。
4. 結果をSlackに自動返信
   • 抽出されたデータが、質問が投稿されたSlackチャンネルに自動で返信されます 。

理想と現実のギャップ：なぜ「ガチャデータ」に特化したのか

• 「特定イベントに参加し、かつ特定のガチャを引いたユーザーの行動は？」
• 「あの機能とこの機能の相関関係は？」

• 全ガチャ共通 ：売上、消費ジェム数、PU、ARPPU、排出ユニット課金率、売上シェア率
• 特定ガチャ ：ステップアップ/ダーツガチャのステップ毎KPI、スクラッチガチャの交換所情報
• ユーザー情報 ：ログイン日、user_id、level、os、grade_id、課金額

AIと上手に付き合うための「歩み寄り」ルール

• ルール①：名称はIDで指定する
  • ?：「（キャラクター名）ガチャ」の売上
  • ?：「ガチャID: xxx」の売上
• ルール②：略称や曖昧な表現は使用しない
  • ?：「〇〇ガチャ」の売上
  • ?：「ガチャID: xxx」の売上

まとめ：AI活用の鍵は「完璧を目指さないこと」

ゲーム運用における分析データの自動取得BOTはTech Inside Drecomで公開された投稿です。