このポジションを一言でいうと

AI実装の技術的な最終責任を負い、案件ごとの再発明をなくす役割です。実装の品質と、横展開できる型の確立に責任を持ちます。
設計やレビューだけを担うアーキテクトではありません。難易度の高い案件では自ら設計し、コードを書き、実装までリードします。

• 所属：STYZ X AI事業本部 AIソリューション部
• 上長：AI事業本部長（AIソリューション部長の着任後は同部長）
• 雇用形態：正社員（試用期間6か月）
• 想定年収：700万円〜1,800万円（経験・能力を考慮のうえ決定）
• 勤務地：東京都渋谷区千駄ヶ谷（原宿）。出社とリモートの併用（週2日以上の出社が望ましい）
• 就業時間：フレックスタイム制（コアタイム11:00〜16:00）
• 選考：書類選考 → カジュアル面談 → 面接（複数回）→ オファー面談（目安1.5〜2か月）

こんな仕事ではありません

設計書を書いて、レビューして、実装は他人に任せる。そういう仕事ではありません。稼働のおよそ半分は案件に課金される時間で、難易度の高い案件では自ら設計し、自ら書きます。
残り半分が横断業務（技術標準の策定、共通コンポーネントの資産化、ガバナンス）です。「アーキテクト」という肩書きですが、手を動かさない前提の方には向きません。

募集背景

現在、AI実装の技術判断を一元的に担う人がいません。案件ごとに各自が独自の実装を始めており、同じような機能を毎回ゼロから作る状態になっています。案件数が増えるほど、この非効率とリスク（品質のばらつき、セキュリティ審査での指摘、障害）が拡大します。実装の型を確立できるかどうかが、受託事業がスケールするかどうかを決めます。

業務内容

1. 技術選定とアーキテクチャ設計（最終判断）

• 案件ごとのAIアーキテクチャ設計の最終判断（LLM／エージェント構成、RAG、外部システム連携）
• 難易度の高い案件では自ら設計し、実装をリードする
• モデル・フレームワーク・クラウドの選定基準の策定

2. 品質基準の策定と運用

• コードレビューと品質基準の策定・運用
• テスト・評価（eval）の設計指針の整備
• 障害の根本分析と再発防止策の展開

3. 資産化（横展開できる型づくり）

• 再利用可能な実装パターン・共通コンポーネントの設計と資産化
• 案件横断で使える評価セット、プロンプト設計指針、連携アダプタの整備
• エンジニアからの実装ナレッジの吸い上げと標準への反映

4. ガバナンスと提案支援

• AIガバナンス・セキュリティ要件の担保（顧客のセキュリティ審査対応を含む）
• 提案段階での技術的実現性の判定と、工数見積の妥当性検証
• 営業段階のセキュリティチェックシート・技術質問票への回答

評価の考え方

実装の品質と、技術資産の横断利用で評価します。

入社後の立ち上がり

• 〜30日：進行中の全案件の技術構成を棚卸しし、重複実装と技術負債を一覧化する。
• 〜90日：技術選定基準とコードレビュー基準を定め、運用を開始する。1案件でアーキテクチャ設計を主導する。
• 〜180日：共通コンポーネントを2つ以上資産化し、複数案件で再利用されている状態にする。顧客のセキュリティ審査に単独で対応できる体制を整える。

協働と役割分担

あなたが担うこと

技術標準と設計判断。難案件のアーキ設計と実装。品質基準。セキュリティ・ガバナンス。技術実現性の判定

あなたが担わないこと

• 個別案件の実装完遂（AIソリューションエンジニア）
• 業務要件の定義（AIコンサルタント／案件マネージャー・コンサルタント）
• 案件の採算責任（AIコンサルタント／案件マネージャー）
• プロダクト（Mimiria by STYZ X）の技術判断（プロダクトエンジニア）

主に組む相手

• AIソリューションエンジニア（技術判断のエスカレーション先として）
• AIコンサルタント／案件マネージャー（提案時の実現性判定と工数検証）
• プロダクト部（知見の相互還流）

近接ロールとの違い：AIソリューションエンジニアは個別案件の実装完遂を担い、本ポジションは技術標準の策定責任を持ちます。プロダクトエンジニアは自社SaaS「Mimiria by STYZ X」が対象で、扱うシステムが異なります。

稼働の位置づけ：概ね50%を案件課金（難案件のアーキ設計・レビュー）、50%を横断業務（標準づくり・資産化・ガバナンス）とします。この比率は四半期ごとに実績で見直します。

このポジションの魅力

1. 技術標準をゼロから設計できる — 既存の型に従うのではなく、AI実装の型そのものを自分で定義できるフェーズです。
2. 特定プロダクト・インフラの制約に縛られない — 案件ごとに最新のモデル・ツールを選定して即座に適用できます。
3. 業種の幅が広い — 製造、小売、ホテル、HR、コンサルティングと、扱う業務ドメインが多様です。
4. 受託とプロダクトの両方に知見が還流する — 自社SaaS「Mimiria by STYZ X」を持つため、受託で得た知見がプロダクトに、その逆もあります。
5. 経営との距離が近い — 技術的な意思決定が、そのまま事業の勝ち筋の議論につながります。

STYZ と STYZ X AI事業本部について

株式会社STYZ は「民間から多種多様な社会保障をいきわたらせる」をMISSIONに掲げ、置かれた環境にかかわらず誰もが自らの境遇を打破できる社会の実現を目指しています。

これまで、NPO・公益法人向けの寄付プラットフォーム「Syncable」、インクルーシブデザインスタジオ「CULUMU」、システム開発・エンジニアリングを担う「STYZ Tech」の3事業を展開してきました。

STYZ X AI事業本部は、これらで培ったテクノロジー・デザイン・事業開発の知見を掛け合わせ、4本目の事業の柱として2025年7月に立ち上げた組織です。AIを導入すること自体ではなく、企業の業務と組織が実際に変わるところまで支援することを、事業の定義としています。

なぜ、いまAI-BPRなのか

生成AIの活用が広がる一方で、多くの企業では次のような状態が生まれています。

• どの業務からAIを活用すべきか分からない
• 現場の業務や判断基準が属人化している
• PoC（小さく試す検証）は実施したが、現場に定着しない
• AIを導入したが、具体的な成果につながっていない

これらに共通する原因は、業務量・例外処理・判断基準・属人化といった一次情報が整理されておらず、現場の実態が見えていないことです。

私たちはAI-BPR（AIを前提とした業務プロセスの再設計）として、現状把握から業務の再設計、AIの実装、現場への定着までを一気通貫で支援します。「AIで何ができるか」ではなく「この業務をどう変えるか」から入り、構想を描きながら並行してPoCで検証を回す。構想と実装の同時進行が特徴です。

自社プロダクト「Mimiria by STYZ X」

全員の声を、組織の知恵に。 Mimiria by STYZ X（ミミリア）は、対象部門の社員一人ひとりにAIとの対話形式で聴き取りを行い、業務の頻度・工数・判断の理由を台帳に整理するクラウドサービスです。

1. 聴く：既存資料を踏まえて聴き取りを設計し、一人ひとりに業務の頻度・工数・背景・判断の理由まで伺います。
2. 台帳にする：聴き取った内容から判断基準を抜き出し、業務フローや属人化の状況とあわせて、意思決定に使える形で整理します。
3. 測り直す：四半期ごとに再度聴き取り、判断基準の変化を前回と比べます。

目指しているのは、既存資料を整理することではありません。社員自身も明確に言語化できていない判断基準・例外対応・仕事のコツを引き出し、組織で使える情報として構造化すること。そして可視化して終わりにせず、その結果をもとにAI-BPRの優先順位を定め、業務の再設計・実装・定着・継続改善までつなげることです。従来コンサルタントが数か月かけていた現状把握を短期間で実施できる点が、私たちの強みです。

事業構造と組織

STYZ X AI事業本部は2つの事業で構成されています。

• プロダクト事業：自社プロダクト「Mimiria by STYZ X」の開発・販売・カスタマーサクセス。部門単位で導入し、現場の判断基準と業務実態を可視化します。
• コンサルティング・実装事業：Mimiria by STYZ Xを起点としたAI-BPRの支援。聴き取りの設計から分析・報告までを行い、業務改革の論点と優先順位を整理する支援と、To-Be（変革後の業務の姿）プロセスの設計、AIエージェントの実装、現場定着、効果検証まで継続的に伴走する支援があります。

Mimiria by STYZ Xで現場の実態をつかみ、業務課題が見えたところで、業務の再設計と実装の支援へ広げていく。これが私たちの事業の基本形です。

組織はAI事業本部長の直轄で、ビジネス開発部／AIソリューション部／プロダクト部の3部門です。

3部門の部長は採用を予定しており、着任まではAI事業本部長が上長です。

事業の状況

STYZ X AI事業本部は立ち上げ期にあります。SIerのAI推進組織と連携した全社業務改革、EC支援、小売・広告など、業種・規模ともに相談の幅が広がっています。

一方で、この引き合いを継続的に受注・提供につなげる体制と、再現可能な型は、まだ確立の途上です。期末（2027年6月）に向けて各機能の中核メンバーを順次迎えており、いま入る方は「決まったやり方を運用する人」ではなく「やり方をつくる人」になります。

選考で全職種に伺うこと

生成AIツールを日常の業務でどう使っているかを伺います。「生成AIで置き換えた工程」と「試したがうまくいかなかった適用」の両方をお聞きします。

直近のプロジェクト例

• EC支援のコンサルティング会社：業務効率化の診断と、小さく試す検証（PoC）の実装。コンサルティング組織の業務プロセスの再設計。
• 小売業界の広告事業会社：販促計画から効果検証までのバリューチェーンにおけるAI活用の全体設計と、段階的なエージェント導入。
• 電機メーカー：従業員の業務を支援する生成AIツールの構想と、実現性の検証。
• ホテルマネジメント事業のスタートアップ：ML・LLMを組み合わせ、複雑で専門性の高い業務を標準化・効率化するマルチAIエージェントポータルの構築支援。
• 人材評価領域のスタートアップ：評価システムの高度化と、リスク管理の支援。

必須要件

• LLMを用いたアプリケーションまたはAIエージェントについて、本番利用を前提としたアーキテクチャ設計・実装経験（RAG、エージェント構成、外部システム連携のいずれかを含む）
• Pythonでの実装経験と、クラウド（AWS／Azure／GCP のいずれか）上での本番運用経験
• 複数人のチームで技術選定を主導した経験
• 生成AIツールを日常の業務で使い、うまくいかなかった例も含めて説明できること（全職種共通）

検証のみを目的としたPoCの経験だけでなく、その後の本番利用を前提として設計・実装した経験を重視します。

いずれか1つでも該当する方を歓迎します（すべてを満たす必要はありません）

LLM／AIエージェント

• RAG、マルチエージェント、MCP（Model Context Protocol）、Function Calling 等を用いたLLMアプリケーションの設計・実装経験
• Claude API、OpenAI API、Azure OpenAI、AI Foundry、Dify、LangChain／LangGraph 等の実務利用経験

評価・品質

• LLMアプリケーションの評価（eval）設計と、精度改善のサイクル運用経験
• 再利用可能な実装パターン・共通コンポーネントを設計した経験

技術リーダーシップ

• 実装標準・コードレビュー基準を策定し、チームへ展開した経験
• エンジニアチームの技術選定・アーキテクチャ判断をリードした経験

エンタープライズ対応・セキュリティ

• セキュリティ・非機能要件を考慮したシステム設計の経験
• AIガバナンス、モデルリスク管理、エンタープライズ企業のセキュリティ審査対応の経験
• 顧客に対して技術的な意思決定を説明し、合意形成した経験

• 書けるアーキテクトでありたい方 — 設計と実装を分離しない
• 再発明を許せない方 — 同じものを毎回作ることに強い違和感を持つ
• 技術選定を政治ではなく根拠で決められる方
• エンジニアの判断を育てられる方 — 全部自分で決めるのではなく、判断基準を渡せる