# こーひーあーる

#### 自社通販Webアプリケーションの脆弱性診断

期間: 2026年7月 - 2026年9月 / 役割: 主担当（実施スケジュール、検査シナリオ、検査端末）

チーム規模: 2026年の実施は自分が主担当。2024・2025年は別の実施者

内製している通販系Webアプリケーションの年次脆弱性診断。社内で毎年実施するポリシーが近年決まり、2026年の実施を主担当として回した。診断ツールは協力会社提供。

##### 状況

- 頼まれたこと: 年次診断を主担当として回すこと（実施スケジュール、検査シナリオ、検査端末操作）

- 自分からやったこと: 検査ツールのライセンスが約1ヶ月だったので、その期間内に回し切るため検査速度を上げ、診断対象を前年の3つより増やすことを目標にした

- 他の人に頼ろうとしたところ: 検出結果の評価・対応判断（攻撃が成立するか、誤検知か、直すか、来年に持ち越すか）は、本業の開発者へ依頼した。一部は自分でも見て対応した

##### 取り組んだこと

- 検査が遅い原因として、シグネチャ過多ではないかと仮説を置いた

- シグネチャを減らすだけだと、見なきゃいけないものまで削るので、何を残すかの選定をした

- 条件を変えて検査速度を比較した

- 検査用のダミーデータ生成がなかった。検証環境の登録時SQLログから基準データを拾い、メールアドレスなどユニーク項目だけ差し替える簡易シーダーをPythonで実装した

##### 結果

- DASTツール推奨のシグネチャセットから、対象が使っていないNoSQL・OpenID Connect・Java向けなどを外し、検査数を約70%に抑えた

- ダミーデータを使い回しているシナリオで、大量の履歴が顧客に紐づき検査速度が落ちることを特定し、ダミーデータを追加で作った

- 診断対象アプリケーション数を、前年度の3つから9つに増やした

##### 残っていること

- 検査シナリオは、対象が3→9に広がる前提では組んでいなかった

- 商品マスタが検証DBのdump依存のため、販売期間が過ぎると検査が期待通り走らない

- 残したシグネチャは、推奨セットから明らかに対象外のものを除いただけ。網羅性や検知品質までは見ていない

#### AIボイスbot導入支援

期間: 2026年4月 - 2026年7月 / 役割: 途中からの支援（電話シナリオ制作、WebAPI連携）

チーム規模: 主担当2名＋途中からの支援（自分）

繁忙期の着信取りこぼし対策として、リピーター受注をボイスbotに寄せる導入。別部門の試算では毎シーズン数百万円以上の機会損失。botは協力会社提供で、ブラウザGUI上で電話フローと音声認識の応答を組み、外部WebAPIをノードに指定できる。

##### 状況

- 頼まれたこと: 途中ジョインの支援として、電話シナリオとWebAPI連携。現行APIがレガシーで、別案件の新APIとどちらを使うかの提案も上長から求められた

- 自分からやったこと: 電話シナリオを組み、自社APIを繋いで動くデモを出すこと。8月稼働を成立させるために現行APIを使う判断を取りにいくこと

- 他の人に頼ろうとしたところ: 育成・運用設計は必要だと感じて主担当へ委譲を依頼した。部門横断の方針は部門側に、WebAPIリプレイスは別ラインに任せた

- 以前の検証で、新規は通話が長く離脱しやすいことがわかっており、リピーターの電話を自動化する方針が先に決まっていた

- 主担当は既に2人いた。途中から支援で入った

- 今期の繁忙期に間に合わせるとして、誰がいつまでに何をするかを、誰もハンドリングしていなかった

- シナリオを作れる画面は提供されていたが、誰も作っていなかった

##### 取り組んだこと

- 途中ジョインで全体が見えなかったので、空いている手から動くものを出して判断材料を先に置いた。GUIのシナリオエディタで自社システムのAPIを組み、動くものを社内デモした

- 作るだけではなく、自分たちでシナリオを組み続けられる必要があると感じた。音声精度・電話受注の型・運用まで含むため、育成や運用設計が必要と考え、主担当へ委譲を依頼した

- 現行WebAPIのリプレイスが別ラインにあり、5月時点で8月稼働希望だった。スケジュールの成立を優先し、現行APIを使う判断を提案して仮で固めた

##### 結果

- シナリオが「画面はあるが未着手」の状態から、自社API連携で動くデモがある状態にした

- リプレイス待ちにせず現行APIを使う方針を仮固定し、別のWebApp担当者へ引き継いだ

##### 残っていること

- 8月から別案件に入るため、WebAPI連携の支援に集中して途中で離脱した

#### ECモールのフルフィルメント化

期間: 2025年7月 - 2025年9月 / 役割: バックエンド 機能開発担当

チーム規模: 6名 (内、部長1名、要件定義・サービス設計1名、フロントエンド1名、バックエンド2名) ※企画部門や倉庫部門含めると数十名

出品・販売までの自社ECモールを、倉庫での預かり・配送まで担うフルフィルメント型へ寄せる企画。自分はバックエンドの機能開発。取扱商品のコンセプトでは差別化があった

##### 状況

- 頼まれたこと: バックエンドの機能開発担当としてアサインされること

- 自分からやったこと: 全体像が見えず何を開発すればいいかわからない状態だったので、関係部門の業務フロー図・ユースケース・機能一覧まで自分で起こし、開発可能な粒度に落としたこと

- 他の人に頼ろうとしたところ: 企画そのものの意思決定や、部門横断の方針は企画側に残した

- 開発担当として入ったが、システム全体像が不明瞭で、何を開発すればいいかわからない状態だった

- 業務フローはあったが、開発可能な粒度まで落ちていなかった

##### 取り組んだこと

- 企画・倉庫・カスタマー・販売管理・経理など、関係部門を網羅した業務フロー図の作成から着手した（可視化から始める判断は自分）

- システム接点をユースケース図にし、ERPパッケージ運用担当に制約を聞いた。ERPの仕様を変えると在庫管理・販売管理と部門業務が動くことがここで判明し、機能一覧とスケジュールに落とした

- WebAPI経由でERPの受注データを取得する仕様、商品登録・変更、倉庫保管手数料算出のための記録仕様の叩き台を作った

- ECモールWebアプリ・管理アプリのバックエンド初期実装、納品計画登録画面のバックエンドを担当した

##### 結果

- 関係部門を横断した業務フロー図・ユースケース図を作り、開発可能な機能一覧まで落とした

- その後の企画変更は、開発担当の立場から効果を観測できる範囲ではなかった

#### SOAP WebAPIのリプレイス

期間: 2024年9月 - 2025年6月 / 役割: 主担当（アプリ構成・テスト方式・開発環境・CI/CDを設計。APIはエンドポイント単位で分担し、在庫系APIの設計〜実装を担当）

チーム規模: 4名 (内、部長1名、別機能担当エンジニア2名、自分)

10年以上前に協力会社が作った、ERPと各種アプリケーションを連携するSOAP WebAPIを内製化し、RESTishなWebAPIへリプレイスする。上長からの依頼は作り替えと、WebAPIの200系成功率の改善。機能要件に自社で対応できるようにすることも目的だった。

##### 状況

- 頼まれたこと: 協力会社製SOAP WebAPIの内製リプレイス。WebAPIの200系成功率を上げてほしい、という上長リクエスト

- 自分からやったこと: エラーがいつ・どれくらい出ているかを、アクセスログから切り分けること。CI3 EOLを受けてフレームワークと検証手段（テスト・CI・コンテナ）を選定し、分担した在庫系APIの設計〜実装まで担うこと。成功率はオンライン連携の枠で通すことに寄せた

- 他の人に頼ろうとしたところ: 早朝帯のリカバリー実装は上長および同僚へ依頼した。他エンドポイントは分担した同僚へ。テーブル定義は協力会社・運用が手動SQLで管理していたので、アプリ側では持たなかった

- 上長から作り替えと成功率改善の依頼を受けたが、実際のエラー発生率や条件はチームで把握していなかった

- ERPとその他アプリの不整合は見えていたが、原因はわかっていなかった

- CodeIgniter3がEOL。社内のWebApp内製が触れる言語はPHP。テーブル定義は協力会社・運用が手動SQLで管理しており、アプリ側のマイグレーション対象ではなかった

- テストコードが勤め先のシステムでほとんど書かれていない状況だった

##### 取り組んだこと

- 現行サーバ（IIS）からSOAP WebAPIのアクセスログを取り、早朝帯にエラー率が約10%の時間帯を見つけた。単独では原因まで閉じられず、相談の結果、ERPのDB index再作成と時間帯が重なることが判明した

- 早朝帯は明示的に503を返すようにした。連携できていない分のリカバリーは上長および同僚に方法の検討と実装を依頼した

- 既存はC#、DBはSQL Serverなので.NETに寄せる選択肢もあったが、社内のWebApp内製チームが触れるのがPHPなので寄せなかった。CodeIgniter3はEOL、4は書き方が大きく変わるため、Laravelでプロトタイプを作って提案し、採用した

- セキュリティパッチの当てやすさ、環境の再配布のしやすさ、セルフホストGitLabのCI/CDとの相性から、Podmanでのコンテナ環境を自ら選定して導入した

- 既存C#コードから仕様を復元できる、という部長の仮説を受け、協力会社が10年前に作ったC#製アプリケーションを解析してLaravelで再実装した

- 在庫系REST APIエンドポイントおよびIN/OUT設計（エンドポイント単位でチーム分担）

- OpenAPI仕様書と実装の乖離を検知するPHPUnitテスト（league/openapi-psr7-validator）、GitLab RunnerによるCI、Pint・PHPStan（Larastan）・PHPUnitをgit pre-commitで回す仕組みを入れてメンバーに配布した

- 構成はMVC+UseCase。オニオンアーキテクチャかで悩んだが、組織の身の丈に合わせてこちらを選んだ。UseCaseのフィーチャーテストを重点的に書いた

##### 結果

- 早朝のエラー帯をログで特定し、原因候補（ERPのDB index再作成との重複）まで辿った。自分はオンライン連携で通すことに寄せていたが、その枠では良い手が出せなかった。早朝帯は明示的に503を返すようにしたため、ログ上のエラー数は増えている（約0.3%→約0.8%）

- Pint・PHPStan・PHPUnitで機械的に検証が回るようになり、共通処理を触ったときにどこが壊れそうかのあたりがつけやすくなった。PHPUnitで、どこまで作ってどこまで確認したかが見えるようになった

##### 残っていること

- 1コンテナ運用のため、デプロイ時のダウンタイムは0ではない。リクエスト数が少ないのでその判断を取った

- コンテナの運用手順が、停電対応などを担う運用担当まで渡っていない

#### ブラウザソーシャルゲームの追加開発・保守

期間: 2015年7月 - 2018年6月 / 役割: サーバサイドPHPのプログラマ

チーム規模: 5名 (内 ディレクター1名、プランナー1名、Webデザイナー1名、プログラマ2名)

Flashで遊べる版権ソーシャルゲームのサーバサイド追加開発・保守業務

##### 状況

- 頼まれたこと: サーバサイドPHPの追加開発・保守

- 自分からやったこと: スロークエリと課金アイテム増殖など、イベントや売上に直撃する不具合の切り分けと修正

- 他の人に頼ろうとしたところ: プラン・演出・クライアントはそれぞれの担当に任せた。レベニューシェアの事業条件そのものは事業側に残した

- レベニューシェア型のプロジェクトで、プラットフォーム・版元・権利取得会社へのマージンなどを加味した上で、チームで毎月数千万の売り上げを求められる現場だった

- フレームワークのないPHPコードベースで、共通の置き場やテストがなかった

- イベント終了間際になるとサーバ負荷が高くなりゲームが重くなる状態だった

- 課金アイテム増殖などのデータ不整合が頻発している状態だった

##### 取り組んだこと

- あるデッキを組んで連続どこまでバトル勝利できるか、などのバトルシステムのWebシステム追加開発

- MySQLのクエリログを分析し、コード内ループでのSQL大量発行とスロークエリを特定し、インデックス追加とクエリ改善を入れた

- 増殖の原因として、全テーブルがMyISAMで行ロックもトランザクションもなく、アプリ側の排他もなかったことを切り分け、楽観的排他制御を入れた

##### 結果

- 新規バトルシステムの追加開発を担当してリリースした

- スロークエリを特定し、インデックス追加とクエリ改善を入れた

- 課金アイテム増殖に対して楽観的排他制御を入れた

##### 残っていること

- イベント終了間際のピーク負荷は、インデックスとクエリ改善では消し切れなかった

- 楽観ロックを入れたあとの、増殖の再発頻度は測っていない