(記事)
Fieldnotes.
開発過程での手法と、実測値。
3Dコンフィギュレーター9 分3Dコンフィギュレーターの四層アーキテクチャ：折りたたみ自転車の開発記録モデル、ルール、データ、持ち帰りの仕組みを層に分ける設計と、導入に向かないケース。3Dパフォーマンス8 分3Dモデル最適化の前後比較：ダウンロード量とメモリの実測圧縮方式がダウンロード量とビデオメモリに与える影響を、実測値で比較。AIハルシネーションと質問応答の検証7 分RAG企業ナレッジQ&Aにおける逐語検証フロー約1,600件のドキュメントで実際に動かした結果をもとに、抜粋を原文と一字一句照合する流れを解説。情報セキュリティ6 分脆弱性スキャンとペネトレーションテストの違い法規が求める実施頻度と、公共部門のセキュリティ業務に対応する実務。外注先の評価5 分ソフトウェア外注ベンダー評価表と契約前の確認事項ベンダー評価でそのまま使える項目と、判断の仕方。3Dパフォーマンス14 分Web 3Dパフォーマンスエンジニアリング：計測・予算設定から検収までの全工程3Dサイトの動きを滑らかにするには、まずボトルネックが読み込み・メモリ・フレーム単位のどこにあるかを計測し、予算を定め、ボトルネックに合った対策を選び、最後は再現できる数値で検収する。AIハルシネーションと質問応答の検証13 分AI質問応答の公開前評価：固定テストセット、信頼度のしきい値、回答拒否の設計AI質問応答は公開前に、固定のテストセットで信頼度のしきい値を測り、根拠を一点ずつ検証し、答えられない場合は明確に回答を拒否して担当者へ引き継ぐ。外注先の評価11 分既存システム引き継ぎのための全コード診断：候補の洗い出しから納品可能なレポートまで既存システムの引き継ぎではまず全コード診断を行い、最後の工程で自らの発見をあえて覆し、レポートには顧客が実際に遭遇する問題だけを残す。3Dコンフィギュレーター12 分外注3Dモデルの受け入れ・再現・検収フロー外注モデルは原材料として扱う。受け入れ時に項目ごとに突き合わせ、公開用ファイルは元データから再現できる状態にし、検収は測定可能な数値だけで判断し、スクリーンショットでは判断しない。GEOとAI検索での可視性12 分SEO・AEO・GEO とは：違いと実施の順序SEO は順位を、AEO は直接の回答を、GEO は AI の回答での引用を目指す。まずインデックス登録を整え、次に引用できる内容を用意する。GEOとAI検索での可視性14 分3Dサイトの検索・AIクローラーへの可読性：プリレンダリング、クローラーの振り分け、構造化データ3Dサイトはまずテキストを HTML に含め、そのうえで用途別にクローラーを振り分ける。検索用とアシスタント用は許可し、学習用は事業判断で決める。情報セキュリティ11 分公共部門プロジェクトの納品・運用の証拠：要求仕様書、確認条文、読み取り専用スクリプト公共部門の検収は要求仕様書に記載された文書と数量で判断され、運用は確認できる証拠で判断される。そのため納品は、要求仕様書を一字一句書き起こすことから始まる。3Dパフォーマンス11 分3Dパフォーマンス数値の計測誤差と信頼できる計測方法数値として有効なのは、実GPU上で、読み込み完了後に、操作を終えてベースラインに戻る状態で測ったもの。前後2つの版の比較は、交互に計測して中央値を取る。AIコンテンツとコスト12 分AI一括生成コンテンツの品質ゲート：既存コンテンツを集計し、検査可能なルールを定めるまず既存ページを集計し、プログラムで検査できるルールを定める。根拠が見つからない項目は空欄にし、リスクに応じて抜き取りレビューを行い、最も高価なモデルには難しい事例だけを任せる。スキャンとデジタルツイン12 分3D Gaussian Splatting をウェブで動かす際のボトルネックと段階化戦略3DGS をウェブで動かす際のボトルネックは、多くの場合ポイント数ではなく重なり層の数。ハードプルーニングでは重なりを減らせず、オフラインでの統合による間引きと、段階化・チャンク単位のストリーミングを組み合わせる。キャンペーンプラットフォームと管理画面12 分大規模イベントのキャラクターシステム：データ表から 1,440 枚のキャラクター画像とシェアカードを一括生成企画から開発完了まで 2 か月足らずのイベントである。各キャラクターはマスターシートに 1 行を持ち、画像ファイル、シェアカード、フロントエンドは番号で連動し、コースが変われば再出力するだけで済む。キャンペーンプラットフォームと管理画面11 分22 週間の全国イベントのプラットフォーム構築：GPS による到着確認、エネルギーのスコア計算、スマートフォンでの動作性能企画から開発完了まで 2 か月足らず。到着確認はサーバーで計算し、スコアはエネルギー台帳に記録し、順位と抽選はスケジュール処理で生成し、画像は AVIF を用途別のサイズで出力する。キャンペーンプラットフォームと管理画面12 分省庁横断イベントのデータ統合：調査票の統合、会場の重複排除、番号設計企画から開発完了まで 2 か月足らずのイベントである。同じ 15 列のヘッダーで調査票を集め、スクリプトで会場を統合して番号を統一し、取り込み前に 1 行ずつ検証し、フロントは同じデータを参照する。キャンペーンプラットフォームと管理画面11 分オンライン博覧会のフロントエンド構築：289 校の 3D 世界地図と情報設計Three.js で 3D の世界地図を描画し、検索はブラウザ内で処理する。4 年間の協力で、学生数は約 60 人から 12,000 人超に増えた。AIコンテンツとコスト11 分ケータリングのオンライン提案システムの作り方：4 ステップのフォーム、仕様に基づく料金計算、3D テーブル4 ステップのフォームで、サービス、時間帯、人数と会場、要望を集める。システムが候補の料理を絞り込み、モデルが名称と説明文を書く。金額と品数は管理画面の仕様から取得し、確認後に 3D のテーブルへ進む。3Dコンフィギュレーター12 分看板プレビューシステムの作り方：ロゴのアップロード、写真との位置合わせ、3D ショールームSVG のロゴをブラウザ内で立体文字に変換し、サンプルの建物や店舗の写真に取り付ける。写真はサーバーに送信されず、トップページでは KTX2 テクスチャと事前コンパイルで読み込みを制御する。3Dコンフィギュレーター13 分新築物件の 3D 内見サイトの作り方：モデルのパッケージ分割、クリッピングプレーンによる階の選択、室内 360 パノラマ外観モデルは分割・圧縮したパッケージにして必要に応じて読み込み、階の選択にはクリッピングプレーンと半透明の外殻を使う。パノラマは間取りタイプごとにカメラ位置を共用し、スマートフォンではより小さいテクスチャと軽量な夜景に切り替える。キャンペーンプラットフォームと管理画面13 分懸賞キャンペーンプラットフォームの会計処理、不正対策、予算管理懸賞キャンペーンの景品は帳簿として扱う。各記録に一意の番号を付け、書き込み前に会員をロックする。不正対策は新規ユーザーを待たせる方法に頼らない。予算は管理画面での検証として実装し、超過した設定は保存できない。AIハルシネーションと質問応答の検証11 分AI質問応答の公開後：回答拒否のしきい値、不正利用への備え、信頼性の維持公開後に最も高くつく問題は、誤答に誰も気づかないこと。守り切るには、測定した回答拒否のしきい値、モデル呼び出しの経路ごとの防御、用途別に分けた利用枠、そして毎日のデータ品質チェックが要る。3Dパフォーマンス10 分GLB ファイルが大きすぎるとき：ジオメトリより先にテクスチャを見るGLB が大きすぎる原因は、多くの場合ジオメトリではなくテクスチャにある。ファイルが小さくても GPU の使用量が小さいとは限らない。圧縮後に約 1 KB の単色テクスチャが典型的な反例である。3Dパフォーマンス13 分スマートフォン3Dのメモリ予算：スマホに残す機能とデスクトップ限定にする機能まずセッション全体のメモリ上限を決め、テクスチャ・ジオメトリ・キャッシュを MB に一つずつ換算する。合計が上限を超える機能は品質を下げるかデスクトップ限定にし、公開後に削るのではなく事前に判断する。外注先の評価10 分3D商品展示サイトの費用は何で決まるか：見積と範囲の読み方3D商品展示サイトの価格差は、モデルを作り直すか、インタラクションをどの層まで作り込むか、スマートフォン対応をどこまで行うかで生まれる。最終的な支払額を左右するのは、単価よりも見積書の範囲条項である。AIコンテンツとコスト9 分AIプロジェクトの費用の見積り方：見積りが数倍ずれる理由見積りには、ラウンド数に1ラウンドあたりの平均コンテキストを掛け合わせる方法を使い、エージェント数や人数では見積らない。数倍ずれる原因は、多くの場合、リトライのラウンド数、思考に使われたトークン、そしてキャッシュが効いていないことにある。情報セキュリティ9 分脆弱性スキャンレポートを受け取った後：修正の優先順位、誤検知への異議申立て、再テストレポートそのものは成果ではなく、対応を終えて初めて成果になる。まず本物の問題と誤検知を分け、悪用されやすさの順に優先順位を付け、最後に再テストで確認できる証拠を残す。長期の運用保守と協業9 分顧客の目標を検収に組み込む：要件から成果指標までPOLISHは協業の初期にプロジェクトが解決すべき課題を聞き出し、目標を検収で確認できる項目に分解し、リリース前に報告用データの残し方を決める。長期の運用保守と協業9 分長期アウトソーシング協業の二つの軸：契約条項と関係的ガバナンス契約が範囲と責任を定め、関係的ガバナンスが契約に書かれていない事柄を扱う。研究は両者が補完し合うことを支持しており、公共部門の外部委託には書面契約と監督を求める法規もある。長期の運用保守と協業8 分設計案件の入札から開発案件の入札へ：公共部門のプロジェクトはシステムの知見をどう引き継ぐか同じチームが設計案件の入札から開発案件の入札まで続けて担当し、データの引き継ぎ、決定事項、年度ごとの帳票を一か所にまとめて残すことで、フェーズが変わってもシステムの知見が途切れない。長期の運用保守と協業9 分共有チャンネルでプロジェクトを管理する：要件、意思決定、リリース通知を記録に残す共有チャンネルの価値は、決定事項を双方が見られる場所に残すことにある。そのためには利用ルールを取り決め、メッセージによる作業の中断を抑える必要がある。長期の運用保守と協業8 分複数機関にまたがる年度プロジェクトの連携リズム：定例会議、報告リスト、リリースチェック関わる人が増えるほど、毎週固定の定例会議、一本化したデータ総括表、リリース前後それぞれ一部ずつのチェックリストが必要になる。長期の運用保守と協業8 分役に立つSLAの書き方：重大度の区分、未達成時の扱い、プロジェクトごとに取り決める目標SLAの価値は、区分が明確で、未達成時の扱いがはっきりしていることにある。対応時限はプロジェクトごとの取り決めに従って契約に明記し、メンテナンス告知、バックアップ、データエクスポートも併せて盛り込む。長期の運用保守と協業10 分システム異常時の対応フロー：通報、修復、通知、事後報告あらかじめ宣言の条件と役割を定め、報告、再現、暫定対応、修正、通知を同じ流れで進める。事後レビューでは責任追及を行わず、変更と復旧の記録を残す。長期の運用保守と協業9 分リリース後の定例運用保守：報告対応、定期点検、運用保守レポートの進め方リリース後の作業は決まった順序と周期で進める。報告はまず登録してから対応し、定期点検はそれぞれ記録を残し、運用保守レポート用のデータは事前に用意し、定例作業と例外作業は分けて記録する。長期の運用保守と協業10 分リリース後に運用保守を続ける理由：ソフトウェアの進化、情報セキュリティ更新、技術的負債システムは使われ続ける限り、環境や情報セキュリティの要求に応じて変化し続け、保守しなければ劣化する。POLISHは運用保守を定例作業と例外作業の二種類に分け、どちらも記録を残す。長期の運用保守と協業8 分合意した範囲外のPOC：まず機会を検証し、組み込むかどうかは顧客が決めるPOLISHは合意した範囲外の機会を見つけたら、まず自ら提案し、小規模な検証を行い、画面と結果をもとに話し合ったうえで、組み込むかどうかを顧客が決める。範囲管理はこれまでどおり並行して進める。
条件に合う記事はありません。
(お問い合わせ)
Start a project.
三つのステップで、判断に足る進め方と予算帯が得られます。
- 01最初の打ち合わせを予約：時間を選びます。完全な仕様は不要です。
- 02オンライン相談（15〜30分）：進め方の方向性、予算帯、スケジュール案を提示。
- 03素材を確認したうえで、約3〜5営業日で見積書兼納品仕様明細書を提出します。
- メール
- hello@polish-design.com.tw
- 郵送先住所
- (104) 台湾 台北市 中山区 植福路191-1号 3F
