ID:42929さん

### 概要 AIが生成したHTMLを、Markdownの制約なく認証付きURLで社内共有できるツール「HTMLShare」を企画・開発・運用。生成AIの普及で「AIに作らせたHTMLレポートやプロトタイプを安全に共有したい」というニーズが高まっていることに着目し、自ら企画を提案。 ### 体制と役割 - 企画・開発・運用のすべてを1人で担当 - 提案当日に承認 → 同日中にMVP完成 → 翌日デモ → **提案から3営業日で本番デプロイ**(Claude Code等のAIコーディング支援をフル活用) ### 背景・課題 - ディレクターやデザイナーなど非エンジニアもAIでHTMLを生成するようになったが、認証付きで安全に共有する手段がなかった - Markdownベースの社内共有では表現力に制約があった ### 取り組み - **アーキテクチャ設計**: React + Vite / Hono on Lambda / Auth0 + Google OAuth / S3 + CloudFront OAC / DynamoDB によるサーバーレス構成 - **MCP対応の認証設計**: OAuth broker + 動的クライアント登録(DCR)を自前で設計し、ユーザーはURLを貼るだけでMCP接続でき、かつ共有者を特定可能に(マネーフォワードでの認可基盤開発の経験を応用) - **マルチインターフェース提供**: WebUIに加えMCP/CLI/SDKを提供し、AIエージェント・バッチ・CI/CD・バックエンドなど様々な経路から連携可能に - **Slackプレビュー対応**: User-Agent判定ではなく署名検証付きApp Unfurlingを採用し、認証コンテンツを守りながらメタ情報のみ展開 - **フィードバックループの構築**: Slack + Zapier でツール名や共有URLドメインに言及する社内会話を自動収集する「エゴサチャンネル」を構築し、要望・バグを即日改善するサイクルを運営 ### 成果 - リリース(2026年6月末)から約3週間で、社内の約10名がアップロード・共有に利用、月間共有数十件 - ディレクター陣が Google Analytics + BigQuery のデータをAIでHTMLレポート化して週次/月次共有する運用が定着 - デザイナー陣が Figma から起こしたHTMLを Claude Code でブラッシュアップし、社内や外部クライアントへの共有に活用 - 社内ツールの脆弱性検出Botが定期レポートをHTMLで出力するようになり、アナウンスに活用 - 開発の経緯・技術詳細をテックブログで公開: https://kodansha.tech/ja/blogs/html-share

### 概要 講談社の内製開発組織 KODANSHAtech にて、企業の広告・プロモーション担当者向けのコンテンツ検索サービスに、AIチャット型の自然言語検索機能を追加するプロジェクト。従来のカテゴリ・タグ検索では「特定業種のキャンペーンに合う、20〜30代女性に人気のコンテンツ」のような複合条件のニーズに応えられない導線課題があった。 ### 体制と役割 - 体制: ディレクター1名・デザイナー2名・エンジニア2名 - 役割: **開発全般を単独で担当**。編集部からの「AI検索を導入したい」という要望を受け、PoC を1人で作成して編集部に提示、フィードバックを受けてブラッシュアップを重ねる形で企画段階から主導。UI・導線の最終調整はディレクター・デザイナーと協業 - 期間: PoC から本番リリースまで約10ヶ月(純粋な開発実装は約2ヶ月。残りは編集長のフィードバック反映、社内AIワーキンググループの利用許諾プロセス、営業向けデモとその反映、問い合わせフォーム・導線の同時改善など、**大組織でAI機能をリリースするための合意形成・ガバナンス対応を完走**) ### 背景・課題 - 掲載作品数・事例記事が膨大で、目的の情報に到達しにくい - 検索ニーズが複合的(業種×ターゲット層×企画内容)で、既存のカテゴリ・タグ検索では構造的に対応できない ### 取り組み - **アーキテクチャ設計**: AWS Bedrock Knowledge Base を核とした RAG 構成を設計(回答生成: Claude Sonnet 4.6 / リランキング: Cohere Rerank v3.5 / ベクトルストア: Amazon S3 Vectors / ECS Scheduled Task による日次データ同期) - **検索精度の向上**: Query Decomposition と Rerank モデルの活用 - **回答品質の評価フレームワーク構築**: ルールベース評価と LLM ベース評価を組み合わせ、フレームワーク上の品質スコアを **70〜80% → 80〜90% に改善**。同一テストケースを何度も試行できる仕組みにより応答の傾向を可視化し、最終チューニング(編集者の勘所による手動テスト)を効率化 - **引用の信頼性担保**: システムプロンプトを Markdown 見出しから XML タグ構造に変更し「1文=1事実」ルールを明示することで、引用粒度の問題を解決 - **非エンジニアが運用できるプロンプト管理**: WordPress 管理画面から編集部が編集できるパートと、コード側で自動付与する不変ルールを分離 - **UXを重視したフロントエンド実装**: SSE によるストリーミングレスポンス+バッファリングによる滑らかなタイピング表現、引用表示 ### 成果 - ビジネス要件(回答の正確性・安全性)を担保する評価・運用の仕組みごと納品し、編集部が自律的にプロンプトを運用できる状態を実現 - 開発の知見をテックブログで公開: https://kodansha.tech/ja/blogs/rag-powered-manga-ip-search

### 概要 講談社の広告主・マーケター向けオウンドメディア「Cステーション」のリニューアル開発と、リニューアル後の開発全般。 ### 体制と役割 - 体制: 講談社の編集長1名+KODANSHAtech(ディレクター1名・デザイナー1名・エンジニア2名) - 役割: リニューアル時はフロントエンドを担当(もう1名のエンジニアと分担)。シニアエンジニアがリードして CMS(WordPress)・データ移行を担当する体制 - **リニューアル後はシニアエンジニアの離任に伴い、CMS・インフラを含む開発全域をメインエンジニアとして引き継ぎ**、以降ほとんどの開発を担当 ### 背景・課題 - 記事約4,000件を抱える大規模メディアのリプレイスで、SEOを毀損せずにパフォーマンスとメンテナンス性を改善する必要があった ### 取り組み - **Astro による SSR フロントエンドの設計・実装**: WordPress の DB に直接 SQL を発行して記事情報を取得する構成で、CMS の管理機能とフロントの表現力・パフォーマンスを両立 - リニューアル後は CMS(WordPress)・インフラ(AWS)を含むフルスタックでの機能開発・運用を主導 - **非エンジニアが Claude Code で自走できる開発環境づくり**: 「ディレクターやデザイナーも AI コーディング支援を使って自分たちで修正できるべき」と考え、ローカル環境構築の自動化を率先して実施(以下3点を合計約3日で整備)。**構築の所要時間を3時間→30分に短縮し、うち人の実作業はスクリプトを3〜4回実行するだけ**(残りはツールのダウンロードや devcontainer のビルド等の待ち時間)。専門知識がなくても誰でも最新の本番データで環境を再現できる状態にした - シークレット設定の自動化: 1Password から手動で env に転記していた作業を、1Password CLI を使ってスクリプト化 - 本番データ同期の脱属人化: 手動の mysqldump + 環境ごとの加工に依存し属人化していた本番データ同期を、マイグレーションツールとして整備し、コマンド実行だけでローカル環境を構築できる状態に - ローカル再現性の向上: CloudFront のルーティングで実現していた静的ページ表示を、Vite プラグインを自作してローカルでも再現できるように - 運用の延長で編集部の課題を拾い、RAG 自然言語検索機能の企画・開発に発展 ### 成果 - 記事約4,000件・Google検索経由で月間232万表示・2.6万クリック規模のメディアを、少人数体制で安定運用 - リニューアルを起点に、AI検索機能などメディアの価値を上げる企画を自ら提案・実現するサイクルを確立 - 属人化していたローカル環境構築を自動化し、非エンジニアも AI コーディング支援を使って開発に参加できる土台を整備(HTMLShare と併せて「組織全体が AI を活用できる状態を作る」取り組みとして継続中) - 関連アウトプット: [Claude Code で WordPress プラグインを解析 - 再現できなかった不具合を解決](https://kodansha.tech/ja/blogs/claude-code-with-wordpress-development)

### 概要 Yahoo の社内プラットフォームチームにて、多数のサービスが利用する HTMLテンプレート配信 WebAPI を開発。性能要件は10万rps。 ### 体制と役割 - 社内プラットフォームチームのエンジニア。チーム内で最もフロントエンドに詳しいメンバーとして、フロントエンド関連の設計・育成をリード ### 背景・課題 - 10万rps の性能要件に対し SpringMVC では限界があり、SpringWebFlux への移行を実施 - 移行検証で作成したデモアプリが SpringMVC と同等のパフォーマンスしか出ないという問題が発生し、チームでの分担調査でも原因が特定できず行き詰まっていた ### 取り組み - **WebFlux 移行のボトルネック特定**: 公式ドキュメントと技術記事から Non-Blocking 処理の技術構成を深く理解した上で、アプリケーションの起動ログから「App サーバが Non-Blocking に対応していない」ことを突き止め解消。スプリント最終日に他メンバーが諦める中、最後まで調査を続けて特定 - **負荷試験環境の構築**: locust を使った攻撃サーバーを構築し、性能要件の検証サイクルを整備 - **データフローの見直し**: キャッシュ化の余地がある箇所を改善し、配信テンプレートを利用者側でキャッシュできるようデータフロー・WebAPI・テンプレートを再設計 - **Kubernetes マイクロサービスの設計**: 運用で肥大化した manifest を helm で共通化しメンテナンス性を向上 ### 成果 - 性能要件である 10万rps を達成 - フロントエンド勉強会の開催・ペアプロの実践により、フロントエンド経験者不在だったチームのスキル底上げに貢献(詳細はマネージメント能力欄)

- レガシーなシステム(PHP5/オンプレ)からモダン環境への移行(Laravel/AWS)にバックエンドエンジニアとして携わりました - オフシュアでの業務委託先とのやり取りを担当して、深層学習を利用した画像判定APIのインターフェス設計などに携わりました - 時間外に発生したDBのトラブル時などに原因を調査して緊急対応を行いました - 企画の方の定形作業をGAS/Slackなどを連携させた自動化を提案し、業務効率の向上に貢献しました - 新機能開発時には企画・デザイナーと要件定義から入り、要件のドキュメント化やデモを見せて認識合わせを行い、手戻りが少なくなるよう開発しておりました #### 実績 休日にサービスがエラー画面が出続けている障害が発生していることをSlackで検知した。 急いで会社に向かい、原因の調査を行い、エラーメッセージからDBのコネクションが枯渇していることを突き止めた。 データベースにアクセスし、ゾンビコネクションが大量に発生していることを確認し、コネクションの削除とmax-connectinの引き上げを行った。 障害の概要と応急処置の内容をドキュメントに残して、後日ポストモーテムを主導で行い、対策防止に努めた。