PORTFOLIOSELECTED WORKS / UX · PRODUCT · AI

現場の判断を、
使える仕組みへ。

2 apps / thought to working product

考えたことを、
動く形まで。

掲載した2件は、企画・コンセプト設計、ビジュアル設計、情報設計、実装、検証までを本人が一貫して担当。考えたことを、現場で使える仕組みへ落とし込んでいる。

Portfolio type 02 / applications

判断を、動く仕組みへ。

集計、比較、進捗管理など、業務や運用上の判断を実際に動かして確かめるために制作した2つのアプリ・運用基盤。

1. Amazonキーワード勝ち負け判定ダッシュボード

Case 01 / Decision-support application

検索キーワードの勝ち・負けを、
再現性と採算で判定する。

01 / 判断の入口

勝ち・負けを、根拠とともに一画面へ。

最新期間の購入数だけで並べず、反復回数、Score、Click条件、ROASを併記し、判断の入口を一つにした。

ブランド、広告区分、判定期間、訴求軸／ブランドKWで絞り込む。
勝ち60件、負け45件、判断保留15件を同じ母集団で把握する。
公開デモは実在しないブランド・商品・数値だけで構成。

02 / 集計の土台

期間と比較軸を固定し、数字の土台をそろえる。

ブランドと広告区分をまたぐ前に、選択期間の売上・費用・効率・母数を同じ条件で再集計する。

広告売上、広告費、ROAS、購入数を第一階層に置く。
Click、CVR、CPA、CTR、CPCまで同じ期間定義で確認する。
比率は単純平均せず、合計値から再計算する。

03 / 訴求・KW分析

検索語を訴求軸へ束ね、キーワード単位まで戻れる。

意味の近い検索語を訴求軸として比較しながら、必要なときは個別KW、商品ターゲット、キャンペーン代理へ掘り下げる。

訴求軸・自然言語KW・SP/SB商品ターゲット・SD代理の4単位を分離。
最新判定と全期間の勝・負・保留を同じ行で比較する。
勝ち側と負け側で訴求軸が混同しないよう、判定群を独立して表示。

04 / 判定基準

一週の偶然を、勝ち筋にしない。

最新期間だけで決めず、クリック母数と全期間の反復を組み合わせ、初回判定と反復判定を分けた。

最低Click、基準CVR、勝ち／負けROASをブランド・広告区分別に設定。
母数不足は勝敗へ寄せず、判断保留として残す。
高ROASでも購入数が少ない対象は、再検証の注意を明示する。

05 / 長期推移

効率と規模を分けて、変化の持続性を読む。

最初にブランド別の長期推移を確認し、その下で主要10指標とROAS×Clickの分布へ進む。

ブランド、広告区分、開始・終了期間をすべて連動。
ROAS、CVR、CTR、CPA、CPCなどを同じ期間軸で横断する。
平均値だけでなく、売上・費用・Click・購入の実数から再計算する。

06 / 変化検知

10指標を、アラートとして一括確認する。

最新値だけでなく、前週比と基準内／外を各カードに持たせ、確認が必要な変化を色と折れ線で示す。

売上・投資・成果・流入・効率を別々のグラフで確認。
ROAS低下、CVR反落、CPA上昇などを基準値と比較する。
色だけに頼らず、数値、符号、ラベルを併記する。

07 / 次回テスト設計

勝利予測ではなく、次に検証すると情報が増える順へ。

判定が切り替わった対象と継続判定を基に、配信拡大、入札見直し、継続観測の候補を採点する。

今週の変化と、実行候補を左右に並べて根拠を追える。
優先度、アクション、対象、反復判定を同じ行で公開。
商品対応未設定や人手確認が必要な対象は、提案から除外する。

08 / 実装・運用

Excelを差し替えるだけで、同じ判定を再現する。

ローデータをPythonで整形・集計し、意味付け結果を結合したExcelをブラウザへ読み込む。画面内の切替では再解析しない。

Pythonで列検証、型変換、集計、判定、結合までを再実行可能にする。
GPTは訴求軸などの意味付けを担当し、数値判定は説明可能なルールへ残す。
Excelはブラウザ内で処理し、外部サーバーへ送信しない。

デモを操作する設計・実装記事

01 / 08

2. 複数AI案件の開発管制室

Case 02 / Local operations system

AIが働くほど、人間は例外だけを見る。

01 / 課題

AIが速くなるほど、進捗管理が先に限界を迎える。

作業を自動化しても、現在地と停止理由を人間が転記するなら、ボトルネックは残る。

複数案件の状態が会話履歴へ埋もれる。
停止理由、試したこと、次の一手、人間判断が別々に残る。
実行→証跡→気づき→次タスクを一つの運用面へ集約した。

02 / 全体像

複数案件を、一つの運用面へ。

稼働、保留、停止、完了を並べるだけでなく、未完了・承認・次の作業を同じ盤面に置く。

案件数、反映待ち、承認待ち、残項目を上部で確認。
未着手から完了まで、状態の違いを列で読む。
生ログではなく、判断に必要な短い状態へ圧縮する。

03 / 進行側

状態だけでなく、次の作業まで持つ。

「進行中」というラベルだけでは再開できない。段階、未完了、次タスクをカードへ残す。

開始・完了・障害・証跡・次タスクをAI側から送る。
作業を中断しても、次に何をすべきかを読める。
人が進捗表へ転記する工程を、イベント記録へ置き換える。

04 / 例外判断

全件を監視せず、人間が見るべき例外を絞る。

止まった理由と完了証跡を同じボードで見せ、人は判断が必要なカードへ集中する。

外部送信、投稿、購入、契約は承認ゲートで止める。
承認を自動実行せず、判断材料を揃えて人を待つ。
停止理由を、通常進行の中に埋もれさせない。

05 / 案件一覧

再開できる単位で、案件を束ねる。

案件名だけでなく、目的、状態、次に必要なことを一覧から詳細へつなぐ。

稼働、停止、完了の件数と案件行を確認する。
検索から、個別の案件カルテへ進む。
「誰が持っていたか」ではなく「どこから再開するか」を残す。

06 / 案件カルテ

目的、次の一手、完了、停止理由を一枚に。

会話を読み返さなくても再開できる、個人用のプロジェクト記憶として設計した。

目的と制約、現在地、成果、未完了を一体化。
証跡、承認履歴、判断基準、知見まで辿れる。
日次の司令室と、後から監査する案件カルテを役割分担する。

07 / 承認と学習

危険な操作は承認待ちへ分け、失敗は次のルールへ返す。

一度の障害記録で終わらせず、再発防止の判断基準へ戻す運用ループをつくった。

短いサニタイズ済みイベントだけを扱う。
危険度の高い操作は、承認待ちとして分離する。
失敗と改善案を、次案件で使うルールへ接続する。

08 / 実装・検証

作った仕組みを、実際の案件運用で使う。

ローカル静的画面、JSON／JSONL正本、Python生成・検証を組み合わせ、個人運用中。

画面生成、データ検証、UIスモーク、セキュリティ、完了条件を確認。
受信停止時は原子的なローカル受信箱へ退避する。
生産性効果、複数人運用、企業向けSaaSとしての適合は未検証。