sato

あなたを気にしている企業

  • ログラスがsatoのレジュメを見ています。
    2026.10.17
  • 弥生がsatoのレジュメを見ています。
    2026.10.16
  • アラカンがsatoのレジュメを見ています。
    2026.10.16
  • メディックメディアがsatoのレジュメを見ています。
    2026.10.16
  • neoAIがsatoのレジュメを見ています。
    2026.10.16
  • SmartHRがsatoのレジュメを見ています。
    2026.10.16
  • BASEがsatoのレジュメを見ています。
    2026.10.16
  • hacomonoがsatoのレジュメを見ています。
    2026.10.16
  • Works Human Intelligenceがsatoのレジュメを見ています。
    2026.10.16
  • アラカンがsatoのレジュメを見ています。
    2026.10.16

キャリアビジョン


シームレスな組織の組成

ビジネスサイドと開発サイド、日本組織とオフショア等海外組織、クライアントと自社など、さまざまな垣根をなるべくシームレスに業務が行える最強のチーム、組織を作っていきたい。 そのために、開発に軸を置きながらも、全体的な知識を吸収し続ける努力をしていく。

プロジェクト経験

2026年/半年以内

営業支援AIエージェント モバイルアプリ 新規開発(Flutter)

営業支援AIエージェントプロダクトのモバイルアプリ版を**1名体制で新規開発**(2026年3月〜現在、業務委託、開発中でプロダクト撤退が決定したため契約終了)。 営業ミーティングの録音・文字起こし・議事録自動生成・話者分離を中核機能とするアプリで、アーキテクチャ設計から実装・α版配布まで一貫して担当しました。 ## プロダクトの概要 営業担当者がミーティング中に録音ボタンを押すだけで、AIが以下を自動生成します。 - **話者分離付き文字起こし**: 誰がいつ何を話したかをタイムスタンプ付きで出力 - **議事録自動生成**: 会議の要約・重要ポイントを構造化 - **ネクストアクション抽出**: 商談テンプレートから次のアクションを自動抽出 ## AI実装のポイント Firebase Vertex AI 経由で **Gemini 3 Flash Preview** を使用し、音声ファイルをマルチモーダル入力として直接渡すことで、外部の音声認識APIを経由しない1ステップの文字起こし・話者分離を実現。 - **プロンプト設計**: JSONスキーマを厳密に指定し、ハルシネーション(架空発言の生成)を防ぐ制約をプロンプトに組み込み - **話者分離**: Geminiの音声理解能力を活用して話者ごとの発言を分離(speaker / text / timestamp の構造化出力) - **フォールバック設計**: JSON解析失敗時も生テキストで結果を返し、UXを損なわない実装 ## アーキテクチャ設計 Layered Architecture + MVVM + Repository Pattern を採用し、1名でゼロから設計・実装。 - **Presentation**: 各ページを page / frame / notifier / use_cases / view_model の5ファイルに分割し関心を分離 - **認証**: Zitadel OIDC(PKCE対応)による企業向けIdP認証。401時のトークン自動リフレッシュ実装 - **録音**: WAV 16kHz モノラルでの音声録音 → Vertex AI へのバイナリ直接渡し - **環境管理**: `--dart-define=ENV=xxx` による local / dev / stg / prd の4環境切り替え - **配布**: Firebase App Distribution を使ったα版の社内配布 ## 担当業務 - アプリアーキテクチャの設計(Layered Architecture + MVVM + Repository Pattern) - Gemini(Firebase Vertex AI)を用いた音声文字起こし・話者分離・議事録生成機能の設計・実装 - プロンプトエンジニアリング(JSONスキーマ指定、ハルシネーション防止制約) - Zitadel OIDC(PKCE)認証フローの実装 - マイク録音サービスの実装(WAV 16kHz) - Firebase App Distribution によるα版配布

2026年/1年以内

家族ハワイ旅行アプリ:AIコンシェルジュ・通訳・キッズモード(個人開発)

### 概要 家族の海外旅行で起こる「次の予定までにどこへ行けるか」「現地の人にどう伝えるか」「移動中に子どもが何を楽しめるか」を、一つのアプリで支える個人開発です。旅程・位置共有・写真共有を土台に、家族の予定を理解するAIコンシェルジュ、対面会話を仲介する日英通訳、子どもが自分で遊び・学べるキッズモードを組み合わせました。特に、会話するAIを実際の行動とアプリ操作につなげる設計に取り組んでいます。 ### 家族の状況を理解するAIコンシェルジュ 予定・便・宿泊先・同行者をFirestoreから取得し、空き時間と移動範囲を把握してから、子ども対応・予算・営業時間などの条件で候補を調べる構成です。旅行データとWeb検索の情報源を分け、古い会話に含まれる予定やAIの推測を確定情報として使わないようにしました。提案だけで終わらず、予定、お気に入り、家族の投票・掲示板などの操作へ接続。読み取り・調査と状態変更を分け、変更には認証済みの権限と確認の経路を設けています。 ### 直訳で終わらないAI通訳 「部屋を替えてほしいが、強い言い方にはしたくない」といった日本語の相談から、意図・トーンを踏まえた英語を作る通訳を実装しています。相手に読み上げる発話と、本人だけに見せる助言をデータ・画面・音声経路で分離。料金、予約変更、個人情報などの重要事項はアプリとサーバーの両側で確認を要求します。「2人、いや3人」の言い直し、翻訳待ちの言い足し、読み上げ中の話者交代を状態遷移として扱い、遅れて届く古い訳が再生される不具合を回帰テストで検出・修正しました。通訳は端末標準TTS、通信断時は基本翻訳・文字提示へ切り替える構成です。 ### 子どもが自分で使えるキッズモード - キャラクターとのAIチャット・通話、VOICEVOXによる読み上げ、日英切替の絵本を用意。絵本の日本語音声はページごとに同梱し、音声モデルの初回ダウンロードを待たずに楽しめるようにしました。 - ひらがな・カタカナ・漢字・数字・算数・英語の学習と書き順練習を実装。遊びの導線と学習の導線を子ども向けの画面にまとめています。 - 専用カメラ、写真への落書き、写真からの塗り絵作成を実装。元写真を残して別作品として保存し、家族へのアップロードは明示操作に限定しました。 - AI通話では発声と認識結果の両方で発話終了を判定し、言葉の末尾を落とさないことと待ち時間の両立を調整。ミュート・終了後に古い応答が再生されたり、マイクが再開したりしないよう制御しています。 ### 開発・検証 Flutter/Riverpod、Firebase、TypeScript、Drift/SQLite、Gemini、ML Kitを使用。オフライン地図・ローカル保存も組み込みました。音声イベントと通信の遅延を再現するテスト、実モデルとの会話比較、iPhoneでの画面・音声検証を分けて実施しており、騒音下の対面通訳など残る実用検証は継続しています。

2025年/1年以内

Otoha:音声SNS・AI歌唱解析アプリ(個人開発)

### 概要 歌や演奏を投稿して交流しながら、歌唱の改善点を具体的に把握できる音楽学習アプリを個人開発しています。録音・再生、投稿、いいね・コメント・フォロー、コラボ録音、歌唱解析結果の表示を扱うFlutterアプリと、独立した歌唱解析ライブラリ/Python APIを開発しています。 ### 担当・技術的な取り組み - Flutter/Riverpod/Freezedを用い、画面、ViewModel、UseCase、Domain、Repository実装を分離。Firebase Authentication・Firestore・Storageと接続し、UIとデータアクセスの責務を整理しました。 - Dartのオンデバイス音声解析で音程、リズム、安定性、ビブラート、強弱を評価。FFTを使うYINとViterbiによる音高追跡、MusicXMLの楽譜と録音の対応付け、区間ごとの評価を実装しています。 - 重い解析をIsolateに分離し、録音・投稿の操作と解析処理が干渉しにくい構成にしました。iOS/Androidの音声デコードはプラットフォームチャネルで接続しています。 - FastAPIによる解析APIと共通の結果契約を用意し、端末内処理とクラウド処理を切り替えられる境界を設計。歌唱コーチングはLLM非依存の契約とルールベースのフォールバックを持たせました。 ### 工夫・現在の状態 単なる総合点表示ではなく、楽譜に対する音程・タイミングのずれと区間別の改善点を返すことを重視しています。無声区間、解析失敗、採点の安定性を回帰テストの対象にしています。現在はアプリと解析エンジンのMVP実装・改善を進めています。

2026年/1ヶ月以内

芸能向けファン・出演者・運営をつなぐプラットフォーム(個人開発)

### 概要 ファン向けのコンテンツ・チケット・物販と、出演者・運営側の業務を、共通のデータと契約でつなぐ芸能向けプラットフォームを個人開発しています。複数のグループ・ソロが同じ基盤を使いながら、組織ごとの情報・権限を分離し、ファン、出演者、スタッフ、管理者にはそれぞれの画面を提供する構成です。機能が増えても組織境界とAPI契約が崩れない基盤づくりに取り組んでいます。 ### 担当・技術的な取り組み - GoのモジュラーモノリスとPostgreSQL、Flutterの4アプリ・共通パッケージ、Next.jsの公式/ファンWebを組み合わせた基盤を構築中です。業務モジュールの責務と依存方向を分離しています。 - OpenAPIを基準にGoのサーバー契約、Dart/TypeScriptのクライアントを生成し、API・アプリ・Web間の契約のずれを検出する開発フローを整備しました。 - テナント境界、RLS、監査ログ、操作の冪等性、一時的な運営サポート権限を設計・実装。組織データの参照と業務更新の権限を分け、監査記録と業務トランザクションの整合性を重視しています。 - 組込みPostgreSQLと架空シードでローカル環境を立ち上げられる構成を用意。生成物、backend、Flutter、Web、依存方向、秘密情報、IaCを共通の検査コマンドで確認する仕組みを整えています。 ### 工夫・現在の状態 画面ごとの実装を先行させるだけでなく、共有契約、認可、監査、データ境界を横断基盤として揃えることを重視しています。現在は基盤と各業務モジュールの実装・統合を進めている段階です。初回リリースに向けた開発段階で、業務モジュールを含む全体の統合・受入検証を継続しています。

2025年/1年以内

マッチングアプリSwift → Flutter リプレイス

マッチングアプリの Swift → Flutter リプレイス開発を担当(2025年3月〜2026年2月、業務委託、全体100名・チーム20名)。 アーキテクチャ設計を主導し、Clean Architecture + Riverpod + Repository Pattern を採用。Melos によるマルチパッケージ構成で関心を分離し、Riverpod / Freezed を活用した状態管理・データ変換方針を整備しました。 ## 担当業務 - Swift → Flutter リプレイス開発におけるアーキテクチャ設計・実装 - 既存機能の Flutter 再実装 - Melos を用いたマルチパッケージ構成の設計・管理 - Riverpod / Freezed を活用した状態管理・データ変換方針の整備 - 既存アプリの保守運用 ## アーキテクチャ Presentation(ConsumerWidget / AsyncValue)→ Repository(AsyncNotifier)→ Service(REST + 独自暗号化 / OmiaiHttpEndpoint で一元管理)→ Domain(packages/domain / 純粋なビジネスロジック)

2023年/2年以内

電子書籍アプリ開発運用およびフルリプレイス

## 大手電子書籍アプリの既存アプリ(Objective-C, Swift混在)運用およびSwiftUIでのフルリプレイスプロジェクト # 既存アプリの運用保守 既存アプリの不具合改修や、API仕様の変更に伴う修正、ライブラリの更新、ストアへのリリース作業などを行っています。 # フルリプレイスプロジェクト 既存アプリが古いコードと混在しており、不具合改修が根本的な解決とはならないため、完全新規でSwiftUIでのフルリプレイスアプリの開発が行われている。 担当は既存アプリにある機能の開発および、リリースに向けてのパフォーマンス改善や、細かなバグ改修、テスト設計など。

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

2022年/1年以内

toC向けアプリ開発

toC向けアプリの開発を2件行っている。 一件はリーダーとして、0→1の開発を立ち上げ、リリースまで行った。 開発メンバーは全体で8名。 iOSアプリ、バックエンド、フロントエンド(管理画面等)の構成。 要件定義から、プロジェクト管理、アプリ開発のコーディングまで一貫して行った。 二件目は、サポート兼オブザーバーとしてジョイン。 開発組織の整理のため現プロジェクトの体制確認や、問題点整理等を行った。 また、開発業務もサポート的に行った。 開発拠点が海外のため、海外開発組織のマネージメント一部を行っている。

2020年/2年以内

レシピ動画アプリプロジェクト

--- # アプリ開発 ## iOSアプリ ### 開発設計 - ### 開発経験 - 開発は主にサブスクリプション提供の機能メインで担当していました。課金画面の改善、課金ボタンの共通化、MVVM化などのリアーキテクチャ、サブスクリプション提供機能の新規開発や追加機能開発などを行っています。 その他にもStore Kit Testingの導入や、部分的に全く別のアーキテクチャを導入し効果検証を行うなどiOS技術 の研究も少しずつ行うようにしています。 苦労したのは、Store Kit Testing導入における、ローカル発行のレシートの取り扱いについてです。 Apple推奨がサーバーでのレシート検証のため、ローカルで発行されたレシートを検証するためには、ローカルで発行された証明書を使用しなければならない為、その対応をサーバーサイドと相談しながら行ったのには、苦労しました。 ---

2018年/2年以内

マッチングアプリ開発

--- # アプリ開発 ## iOSアプリ ### 開発設計 - 機能設計から関わり、技術的に可能であるか、工数がどのくらいか、この機能をつけたらいいのではないかなど提案からビジネスサイドの要望の相談まで行っていました。 - 開発時の設計においては、ライブラリやSDKの選定なども行い、他の経験が浅いエンジニアへの設計サポートなどの支援も行っていました。 ### 開発経験 - 起動画面〜退会画面まで満遍なくほとんど全ての機能に携わっています。特に注力したのは、掲示板型の投稿機能とユーザーセキュリティ機能です。 掲示板型機能はUXを高めるにはどのような構造がいいのかをとことん考え実装しました。苦労したのはレイアウトについてです。限られた画面リソースでどのようにオートレイアウトを設定するべきか悩みました。 ユーザーセキュリティ機能については、主にスクリーンショットへの対策です。第一フェーズとして、スクリーンショット検知とそれに対する警告表示、第二フェーズとして、スクリーンショット時の画像、テキストへの防止策の対応を行いました。 苦労したのはその設計についてでした。(詳しくは記載できませんので口頭で聞いていただければ) ### UX改善 - 開発中UXの改善を特に意識していました。その改善のために、自社アプリを使い倒しました。その他競合アプリに関しても10以上のアプリに自費で課金を行い、調査を行いました。そのおかげで改善点を見つける手がかりを得ることも出来ました。 ## Androidアプリ ### 開発経験 - iOSと異なり、Android開発はpatersが初めての経験になりました。社内にAndroid開発を行える人間が1人しかおらず、iOSと兼任であったためほとんど手を付けられていない状態でした。そこでAndroid開発を自主的に始め、業務外での学習開始から1週間ほどで業務として初めてのPRを出すことが出来ました。このように私は、他の言語、技術であってもキャッチアップの速度には自身があります。 具体的な機能としては、初期起動のオンボーディング画面が記憶に残っています。 まずiOSを先行して開発を行ったのですが、全く同等の機能をAndroidで表現する事が難しく、ライブラリをいくつも試しながら、開発した覚えがあります。 デザインも両OS統一感のあるものにできたので、記憶に強く残っています。 ### 開発設計 - iOSと同様に機能設計から関わっていました。そのため、iOSで実装した直後にAndoidでの同様の実装を行うということを頻繁に行っていました。iOSとの統一性を意識しながら実装を行いました。 --- # Web・API開発 ## PythonでのWeb開発 ### 開発経験 - 主にアプリ内WebView用の特殊なイベント用のページとしてPython(Flask)でのWeb開発を行っていました。Androidと同様、経験の無い言語かつWebフロントの経験がない状態でしたが、早い速度で学習を行うことが出来ました。実際に行ったのが、0からFlaskでのWebAppの立ち上げ、AWS、EC2にFlask環境のサーバー構築、その後の運用、改修等行いました。 具体的な機能としては、オフラインイベントの招待から支払い、当日の入退場管理、イベント後のアンケート取得を行える、社内用イベント管理機能を実装しました。苦労したのは二点あり、一点目は決済用の外部サイトから決済情報を取得し、自社のユーザー情報と突合させる処理でした。 二点目は、当日の入退場管理です。 支払い確認ができたユーザーから画面にユニークなQRコードを表示させ、当日、別で開発したiOSアプリのQRコードリーダーでそのQRを読み込み、APIでサーバーに通知し、レスポンスに本人確認用のユーザー情報を返し、iOSアプリ上で表示させ、その情報に基づいて本人確認を行えるようにした事です。 ## PythonでのAPI開発 ### 開発経験 - API開発に関してはJavaでのAPI開発のみ経験がある状態でしたが、前職においてはPythoでのAPI開発を行いました。用途はアプリでの使用ではなく、自作した社内用iOSアプリ(カスタマイズされたQRコードリーダー)のためのAPI開発でした。クライアントからサーバーサイドまで開発を1人で行ったため、普段気づけないような事を知る機会にもなりとても良い経験になりました。 ---

2018年/半年以内

マンガアプリ開発

# アプリ開発 ## iOSアプリ ### オンボーディング改善 - はじめの業務がオンボーディングの改善でした。チュートリアル作成や、かんたんな初期レコメンドのような画面実装を行いました。実装を行う上で他競合アプリを参考にしながら、改善を出すなど積極的に動きました。 ### 検索機能実装 - 検索機能を1から実装しました。検索機能はAPI(Java)からアプリまで1人で実装行うことになり、設計などを知るとても良い経験になりました。 ## 売上レポートの自動化API アプリでの作品ごとの売上を集計し、詳細なレポートを自動で作成するAPIを実装しました。言語はJavaでの実装です。APIの知識だけでなく、複雑なSQLや複雑な計算式のためのテストなどに苦慮しましたが、とても良い経験にすることが出来ました。

2024年/1年以内

美容医療 / 求人系動画配信アプリ 開発リード(Flutter)

2プロジェクト同時統括の開発リードを担当(2024年7月〜2025年1月、業務委託、チーム16名)。 美容医療系縦型動画アプリとトラックドライバー求人アプリを並行してリード。技術選定・アーキテクチャ設計・基盤設計から実装まで一貫して推進し、**半年で2アプリの開発を完了**しました。

2024年/3ヶ月以内

医療従事者向けスキマバイトマッチングアプリ開発(Flutter)

医療系スキマバイトアプリの Flutter 開発を担当(2024年12月〜2025年2月、業務委託、チーム20名)。 Sentry の導入によりエラー監視体制をゼロから構築。GraphQL + Flutter Hooks(useQuery / useMutation)を用いたデータ取得・更新フローを設計に参加しました。 ## 担当業務 - Sentry 導入によるエラー監視体制の構築 - GraphQL + Flutter Hooks によるデータフロー設計・実装 - Feature-First + Hooks Pattern に基づくディレクトリ設計 ## アーキテクチャ方針 Feature-First 構成:hooks/(ビジネスロジック) / widgets/(UI) / models/(ドメインモデル) / graphql/(Query・Mutation定義) / extension/(ドメイン拡張)

2025年/1年以内

海洋安全・緊急SOS通報iOSアプリ 開発リード

海洋安全iOSアプリの開発リードを担当(2025年1月〜2025年7月、業務委託、スタートアップ10名未満)。 緊急時の新機能「SOSモード」を自ら提案し、要件整理・設計・実装を一貫して担当。**海上保安庁との実地検証を主導**するなど、官公庁連携を含む実運用フェーズまで推進しました。 ## 担当業務 - 緊急時新機能「SOSモード」の企画・提案 - SOSモードの要件整理・設計・実装 - 海上保安庁との実地検証の推進・主導

2022年/1年以内

株式投資ポートフォリオ管理iOSアプリ開発

株式投資管理iOSアプリの開発を担当(2026年1月〜2026年6月、業務委託)。 Swift / SwiftUI を用いた投資管理アプリの機能追加・改善・画面実装を担当。チャート系ライブラリを活用した投資データの可視化UIを実装しました。 ## 担当業務 - Swift / SwiftUI による株式投資管理アプリの開発 - チャート系ライブラリを用いた投資データ可視化UIの実装 - 既存アプリの機能追加・改善・画面実装

2025年/2年以内

enne:ぶどう農園のEC・CMS・受注管理システム(個人開発)

### 概要 ぶどう農園ブランド「enne」の公式サイトを起点に、商品販売から注文・在庫・発送管理までを扱うEC/CMSを個人開発しています。ブランド紹介のLP、購入者向けWeb、管理画面、APIを分離し、農園特有の収穫・発送時期や品種、贈答用途を扱える構成にしています。 ### 担当・技術的な取り組み - ReactのLPからNext.jsのECへ拡張し、TypeScript/pnpm/Turborepoのモノレポに整理。Hono API、Firestore、Cloud Run、Firebase Hostingを組み合わせました。 - 商品・バリエーション、カート、配送条件、Stripe Checkout、注文照会、在庫、発送管理、CMSを実装。通常ギフト、熨斗・メッセージ、eギフトの受取URLと住所入力、PDF帳票も扱っています。 - Zod/OpenAPIをAPI契約の基準とし、Orvalでクライアントを生成。Web/AdminがFirestoreを直接操作せず、業務判断と認可をAPIに集約しました。 - 注文時に最新の価格・販売条件・在庫をトランザクション内で再検証。注文作成の冪等キーとStripe webhookの署名・重複処理を設け、再送で注文や在庫が二重に更新されないようにしました。 - Firebase Authの管理者ロール、eギフト受取人と購入者の情報分離、画像・CMS表示の取り扱いを設計しました。 ### 工夫・現在の状態 画面の購入導線だけでなく、決済の再送、在庫不足、返金、受取期限切れまでを業務フローとして扱っています。Firestore/Auth Emulator、決済stub、Playwrightによる統合・E2Eの検証経路を整備。既存LPを基盤に、開発環境でECの購入・管理フローを検証している段階です。

2026年/半年以内

芸能向けオーディション・応募管理プロダクト(個人開発)

### 概要 芸能グループのオーディションで、募集内容を知るところから、応募情報・写真の提出、運営の確認までをつなぐプロダクトを個人開発しました。3ステップの応募フォームと下書き、LINE/LIFFの入口、応募管理を一体化。応募者が途中で操作をやり直す場面と、運営が応募資料・デモ曲を扱う場面で、保存状態と公開範囲を揃えることに取り組んでいます。 ### 担当・技術的な取り組み - React/TypeScript/Vite、React Hook Form/Zodで応募UIと入力検証を構築。Firebase Functionsを経由して応募を受け付け、Firestore/Storageに保存する構成にしました。 - 管理操作はFirebase AuthenticationのCustom Claimsで保護し、応募・管理用FunctionsではApp Checkと権限を検証。応募下書きの状態と写真アップロード権限をFirestore/Storageのルールで連動させました。 - デモ曲の公開予約、公開プレビューと非公開マスターの分離、短時間の再生URLを実装。募集運用で扱う情報の公開範囲を整理しました。 - 応募CTA、フォームの各ステップ、応募完了、デモ再生、SNS流入元を計測。応募内容や個人情報を送らない日次集計と、GA4の固定イベントによる計測を組み込みました。 ### 工夫・現在の状態 応募者が使いやすいフォームと、運営側が安全に応募を管理できる仕組みを一体で考えています。公開情報の取得と機微な応募・管理操作で保護の強さを分け、公開ページ全体が一時的な認証判定で利用不能にならないようにしました。ルール検証、UIテスト、E2E、ビルドを確認する開発フローを用意しています。公開ページ・応募機能・管理画面を実装し、募集運用を支える改善を継続しています。

2026年/3ヶ月以内

芸能向けAIマネージャー:会話・予定・長期記憶をつなぐ業務支援(個人開発)

### 概要 「会話で決まった予定や約束を、後から実行できる仕事として残す」ための、芸能向けAIマネージャーを個人開発しています。メンバーとの相談、予定、タスク、約束、長期記憶をつなぎ、返答するチャットから継続的な業務支援へ広げるプロダクトです。特に、AIが覚えたつもり・実行したつもりにならないよう、記憶の確定と業務操作の権限・承認・実行状態を管理する仕組みを重視しています。 ### 担当・技術的な取り組み - Flutterのメンバー用アプリ・管理Web、GoのCore API、Python/FastAPIのAI worker、GoのTemporal worker、PostgreSQL/pgvectorを組み合わせたモノレポを構築しました。 - LLMは構造化された計画と回答を返し、DBや任意URLを直接操作しない設計。Core APIがTool名、引数、利用者権限、AIの役割、操作リスク、承認、対象の最新バージョンを検証してから実行します。 - 会話の原文、判断記録、記憶候補、Workflowの正式状態をPostgreSQLに保存。記憶は候補から確定へ遷移させ、Temporalの履歴だけに業務状態を依存させない構成にしました。 - 冪等キーと固定Workflow IDで重複実行を防ぎ、AI失敗時にも保存できるフォールバックを用意。テナント・本人の閲覧範囲でAIに渡す情報を制限しています。 - Cloud Run/Cloud SQL、Terraform、GitHub Actionsによる環境構成を用意し、dev/stg/prdのデータ・権限・サービスアカウントを分離しました。 ### 工夫・現在の状態 AIが自然に会話できることと、業務操作を安全かつ追跡可能に実行できることを別の責務として設計しています。Function Calling、認可、長期記憶、耐久Workflowを結び付ける開発に取り組んでおり、外部資格情報の設定や実運用での受入確認を含めて開発・検証を継続しています。

2026年/3ヶ月以内

芸能向け作曲・歌唱制作支援プロダクト(個人開発)

### 概要 「曲を作る」から「メンバーが練習できる音源を渡す」までをつなぐ、作曲・歌唱制作向けの個人開発プロダクトです。旋律から複数の和声・編曲案を比較し、音域、歌割り、ハモリ、録音、ガイド音源の書き出しへ進めるmacOS/iOS/iPadOSアプリを開発しています。自動生成の結果を受け取るだけでなく、気に入った部分を固定し、編集・比較・やり直しを重ねられる制作体験を重視しています。 ### 実装した機能と工夫 - Swift/SwiftUIで鍵盤、ピアノロール、MIDI取込、単旋律の音声推定を実装。和声候補を比較・採用し、複数パートの編曲とMIDI/MusicXML/WAV出力へ接続しました。 - 和音列の確率と旋律・音域・ボイシング等の制約を組み合わせるSwiftのローカル学習・生成を実装。ネット接続やPython runtimeに依存せず、コーパスの改訂・除外、モデル比較・有効化・rollbackを管理します。 - メンバーの音域、歌詞版、歌割り・ハモリを制作データとして扱い、個人向けのガイド/minus/click音源を出力する経路を用意しました。 - 録音の原本とtakeを保持し、clip編集、内蔵FX、Apple Audio Unitのoffline処理へ接続。SQLiteの原子的保存、Undo/Redo、履歴、バックアップ・復元により、制作途中でも戻れる構成にしました。 ### AIに任せる範囲の設計 日本語対話による操作は型付きコマンドとして検証し、自由対話APIと端末内の制作・保存・音声処理を分離しています。録音、コンピング、補正、ミックス、マスターまでのDAW拡張についても、人とAIが同じCommand Registryを使う設計とJSON Schema、Pythonの契約検証を整備しました。この拡張設計は、既に動作する作曲アプリの実装範囲と区別しています。 ### 現在の状態 Mac、Simulator、iPhone実機でのビルド・候補生成・非無音WAV出力の検証記録があります。同梱学習データは合成和声データです。全制作経路と任意の第三者プラグインの受入を進めながら、制作の自由度と戻せる操作を両立させる開発を継続しています。

2026年/1ヶ月以内

芸能向けクリエイティブ制作プロダクト:画像・映像編集とAI操作連携(個人開発)

### 概要 宣材写真、SNS画像、映像、制作資料を同じ端末で扱える、芸能活動向けのクリエイティブ制作環境を個人開発しています。画像編集・RAW現像・動画編集・素材合成・AI制作依頼の各ツールと共通基盤を、Mac/iPhone/iPad向けの一つの制作アプリへ組み込みました。端末内での制作、ファイル保存、AIからの実操作も開発しています。 ### まとめて扱う制作機能 - 写真・画像編集:レイヤー、文字、ブラシ、マスク、色調整などの編集と画像出力。RAW現像と写真ライブラリの管理・バックアップも扱います。 - 動画編集:素材の取込、タイムライン、カット・配置、テキスト・効果、映像/音声処理、プロジェクト保存・動画出力を扱います。 - 素材づくり:画像・文字・図形の合成、描画、ムードボード・絵コンテ、既存の3Dシーン/動画画面のローカル接続を進めています。参照素材とプロンプトから制作依頼を組み立て、接続するAIへ渡すための契約も整備しました。 ### 移植・統合で工夫した点 Rust/WebAssemblyの編集エンジンとWeb画面をSwiftUI/WKWebViewへ組み込み、端末内だけのlocalhostサーバーで配信しています。保存用originを固定してIndexedDB/OPFSのデータを維持し、WebGPU/WebGLやファイル入出力などWebKitの差を吸収。大きな書き出しはチャンク転送と保存ACKでネイティブの保存画面へ橋渡しし、「ダウンロード要求を出した」と「実ファイルを保存した」を区別しました。 ### AIが実際の編集を操作する仕組み CLI/MCPから操作カタログ・編集状態を取得し、人の画面と同じ編集エンジンで取込・編集・Undo/Redo・書き出しを実行できます。素材、操作予算、成果物、長い書き出しの状態・取消を管理し、要求が受理されたことと制作物が完成したことを分ける設計です。AIによる生成依頼の準備と、外部モデルが生成した成果も区別しています。 ### 検証・現在の状態 編集状態・画素・音声・出力ファイルの比較、実Macでの操作・保存、別プロセスでの再読込を検証しています。芸能制作のワークフローに合わせた個人利用向けの開発を継続しています。

マネージメント能力

エンジニアチーム(3〜4名の少人数チーム)
エンジニアリソースの最適化
個々のエンジニアの能力、性格を把握し、任せる量、チャレンジさせるタイミング、進捗確認するタイミング、ミーティングでの扱い方を工夫しました。 自身も開発タスクをこなしながらのため、なるべく迅速にできるよう、それぞれの開発仕様を確実に把握しておき、実際に軽くコードレビューをして進捗と今後の予想を立て、リソースを最適化する様にしていました。

海外子会社開発グループ(100名前後)
技術力向上、適切なアロケーションなど将来的に継続可能な組織にしていく事
フロントエンドチームでの品質担保のため社内標準ライブラリの開発や、開発速度安定の為、共通UIコンポーネントの作成、継続的な成長、キャッチアップをさせるためデザイナーチームのUI/UXデザインのレビュー体制を整えた。外部のデザイナーをレビューの一部に組み込む事で社外のデザインを学べるよう工夫した。

アピール項目


アウトプット

GitHub アカウント
あり
Qiita アカウント
未入力です
Zenn アカウント
未入力です
Speaker Deck アカウント
未入力です
SlideShare アカウント
未入力です
特にアピールしたいアウトプット
未入力です

今後、身につけなければいけないと思っている技術は何ですか?

- インフラ - DB設計 - AR

あなたが一番パフォーマンスを出せるのはどんな環境ですか?

- 自由な発言、フラットな人間関係、全く別の職種への部分的な挑戦

生成AIの活用状況

日常的な情報収集・業務活用
ChatGPTやGeminiなどのチャットツールを、情報収集、ドキュメント作成、翻訳に日常的に活用
業務でコード補完系の生成AIを活用
GitHub Copilot等のコーディング支援ツール
業務でコード生成、コーディングエージェント系の生成AIを利用
コードレビュー、テストコード生成、デバッグに生成AIを活用
サービス・プロダクトへの応用
既存のサービスやプロダクトに生成AI(API利用など)を組み込み、LangChainやLlamaIndexなどのフレームワークを使った開発経験
生成AIをコアとした開発
生成AIを主要技術としたサービス・プロダクト・機能の企画や、RAGなどの高度な手法を用いた開発経験

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
一人で黙々
どちらかといえば一人で黙々
どちらともいえない
どちらかといえばみんなでワイワイ
みんなでワイワイ
好きな規模
小さい会社
どちらかといえば小さい会社
どちらともいえない
どちらかといえば大きい会社
大きい会社
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 分析力 / 問題解決力
スキルのタイプ
ゼネラリスト
どちらかといえばゼネラリスト
どちらともいえない
どちらかといえばスペシャリスト
スペシャリスト
得意なフェーズ
0 → 1
どちらかといえば0 → 1
どちらともいえない
どちらかといえば10 → 100
10 → 100
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
SI
その他の特徴
新しい技術はとりあえず試す / 趣味は仕事 / 起業/創業期のベンチャーにいた
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

手を動かして設計してコードを書きたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
価値あるプロダクトを作り成長させたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
学び続けて技術力でプロダクトに貢献したい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
意義があることや社会に貢献できる仕事がしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
人や計画の調整・マネジメントをしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
レガシーなシステムの保守・運用・改善をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
企画や仕様を考えるところから関わりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
業務効率を改善して一緒に働く人のためになりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
全社横断的な共通基盤作りや強化をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
組織や文化を作る・成長させる仕事をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい

基本プロフィール

年齢
今年で30代中盤
好きなテキストエディタ
VSCode
希望勤務地
東京都 / リモート勤務
集まる必要性がない場合は基本リモートが許可される環境が必要
希望年収
1500万円
ご意見箱

要望、不具合報告、使いづらい点や感想など、お気軽にお寄せください。
いただいたご意見は、今後のサービス向上に活用させていただきます。

なお、このフォームは受付専用のため、返信を行っておりません。
返信を希望する場合はお問い合わせよりご連絡ください。

  • {{error}}
転職ドラフトを友人や同僚に薦める可能性はどのくらいありますか?