[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article:freee-accounting-integrity":3},{"meta":4,"markdown":119,"quiz":120},{"type":5,"articleId":6,"slug":7,"title":8,"titleEn":9,"category":10,"summary":11,"publishedAt":12,"image":13,"vocabulary":14,"quizId":118},"article","tech-freee-accounting","freee-accounting-integrity","freeeの会計データ整合性 — 仕訳バランスの自動検証","freee's Accounting Data Integrity — Automatic Journal Balance Verification","tech","How freee enforces accounting data integrity through double-entry bookkeeping, idempotency keys for financial transactions, batch reconciliation, audit trails, and safe handling of retroactive corrections.\n","2026-04-27T00:00:00Z","https:\u002F\u002Fimages.yamiyomi.com\u002Ftech-freee-accounting.png",[15,20,25,29,33,37,41,45,49,53,57,61,65,69,73,77,81,85,89,93,97,102,106,110,114],{"word":16,"reading":17,"meaning":18,"level":19},"会計","かいけい","accounting","N2",{"word":21,"reading":22,"meaning":23,"level":24},"整合性","せいごうせい","consistency\u002Fintegrity","N1",{"word":26,"reading":27,"meaning":28,"level":24},"仕訳","しわけ","journal entry",{"word":30,"reading":31,"meaning":32,"level":24},"借方","かりかた","debit",{"word":34,"reading":35,"meaning":36,"level":24},"貸方","かしかた","credit",{"word":38,"reading":39,"meaning":40,"level":19},"検証","けんしょう","verification",{"word":42,"reading":43,"meaning":44,"level":24},"冪等性","べきとうせい","idempotency",{"word":46,"reading":47,"meaning":48,"level":19},"監査","かんさ","audit",{"word":50,"reading":51,"meaning":52,"level":24},"証跡","しょうせき","trail\u002Fevidence",{"word":54,"reading":55,"meaning":56,"level":24},"遡及","そきゅう","retroactive",{"word":58,"reading":59,"meaning":60,"level":19},"修正","しゅうせい","correction",{"word":62,"reading":63,"meaning":64,"level":24},"不変","ふへん","immutable",{"word":66,"reading":67,"meaning":68,"level":19},"取引","とりひき","transaction",{"word":70,"reading":71,"meaning":72,"level":19},"残高","ざんだか","balance",{"word":74,"reading":75,"meaning":76,"level":19},"再計算","さいけいさん","recalculation",{"word":78,"reading":79,"meaning":80,"level":19},"二重","にじゅう","double",{"word":82,"reading":83,"meaning":84,"level":19},"重複","ちょうふく","duplication",{"word":86,"reading":87,"meaning":88,"level":24},"排他","はいた","exclusion",{"word":90,"reading":91,"meaning":92,"level":19},"制約","せいやく","constraint",{"word":94,"reading":95,"meaning":96,"level":24},"一貫性","いっかんせい","consistency",{"word":98,"reading":99,"meaning":100,"level":101},"銀行","ぎんこう","bank","N4",{"word":103,"reading":104,"meaning":105,"level":19},"連携","れんけい","integration\u002Flinkage",{"word":107,"reading":108,"meaning":109,"level":24},"照合","しょうごう","reconciliation",{"word":111,"reading":112,"meaning":113,"level":19},"確定","かくてい","finalization",{"word":115,"reading":116,"meaning":117,"level":19},"締め","しめ","closing","tech-data-architecture-quiz","\n::para\n[freee]{ふりー:freee}は[個人]{こじん:individual:N2}[事業]{じぎょう:business:N4}[主]{ぬし:owner:N4}から[中]{ちゅう:medium:N5}[堅]{けん:firm:N1}[企業]{きぎょう:company:N1}まで[幅広く]{はばひろく:widely:N2}[利用]{りよう:used:N3}されているクラウド[会計]{かいけい:accounting:N4}サービスです。[会計]{かいけい:accounting:N4}データは[一]{いち:one:N5}[円]{えん:yen:N5}たりとも[狂って]{くるって:to be off:N1}はならず、[税務]{ぜいむ:tax:N2}[調査]{ちょうさ:audit:N2}や[監査]{かんさ:audit:N1}に[耐える]{たえる:to withstand:N1}[正確性]{せいかくせい:accuracy:N3}が[求められ]{もとめられ:required:N3}ます。[本]{ほん:this:N5}[記事]{きじ:article:N3}では、[freee]{ふりー:freee}が[仕訳]{しわけ:journal entry:N1}データの[整合性]{せいごうせい:integrity:N1}をどのように[担保]{たんぽ:guarantee:N1}しているかを[整理]{せいり:organize:N1}します。\n\n#en\nfreee is a cloud accounting service used widely from sole proprietors to mid-sized companies. Accounting data must not be off by even one yen, and accuracy that withstands tax audits and external audits is required. This article organizes how freee guarantees the integrity of journal entry data.\n::\n\n::heading\n[複式]{ふくしき:double-entry:N2}[簿記]{ぼき:bookkeeping:N1}の[強制]{きょうせい:enforcement:N3}\n\n#en\nEnforcing Double-Entry Bookkeeping\n::\n\n::para\n[複式]{ふくしき:double-entry:N2}[簿記]{ぼき:bookkeeping:N1}の[基本]{きほん:basic:N1}[原則]{げんそく:principle:N2}は、すべての[取引]{とりひき:transaction:N3}が[借方]{かりかた:debit:N4}と[貸方]{かしかた:credit:N4}に[同じ]{おなじ:same:N4}[金額]{きんがく:amount:N2}で[記録]{きろく:recorded:N2}されることです。[freee]{ふりー:freee}では、[仕訳]{しわけ:journal entry:N1}を[書き込む]{かきこむ:to write:N3}トランザクション[内]{ない:within:N3}でデータベース[制約]{せいやく:constraint:N3}と[アプリケーション]{あぷりけーしょん:application}[層]{そう:layer:N2}の[両方]{りょうほう:both:N3}で[借方]{かりかた:debit:N4}[合計]{ごうけい:total:N3}と[貸方]{かしかた:credit:N4}[合計]{ごうけい:total:N3}が[一致]{いっち:match:N1}することを[検証]{けんしょう:verify:N1}します。\n\n#en\nThe basic principle of double-entry bookkeeping is that every transaction is recorded with the same amount on both the debit and credit sides. At freee, when writing a journal entry, both database constraints and the application layer verify within the same transaction that debit totals match credit totals.\n::\n\n::callout\n[仕訳]{しわけ:journal entry:N1}の[整合性]{せいごうせい:integrity:N1}は「[書き込み]{かきこみ:write:N3}[時]{じ:time:N5}」に[必ず]{かならず:always:N3}[検証]{けんしょう:verify:N1}する。[後]{あと:after:N5}から[気付く]{きづく:to notice:N3}のでは[手遅れ]{ておくれ:too late:N3}です。\n\n#en\nJournal entry integrity must always be verified at write time. Noticing afterward is too late.\n::\n\n::heading\n[冪等性]{べきとうせい:idempotency:N1}キーによる[二重]{にじゅう:double:N4}[計上]{けいじょう:posting:N4}の[防止]{ぼうし:prevention:N2}\n\n#en\nPreventing Double-Posting with Idempotency Keys\n::\n\n::para\n[銀行]{ぎんこう:bank:N4}APIや[決済]{けっさい:payment:N3}サービスからの[連携]{れんけい:integration:N1}データを[取り込む]{とりこむ:to import:N3}[際]{さい:occasion:N3}、ネットワーク[障害]{しょうがい:failure:N1}や[再]{さい:re-:N2}[試行]{しこう:attempt:N4}によって[同じ]{おなじ:same:N4}[取引]{とりひき:transaction:N3}が[二重]{にじゅう:double:N4}に[登録]{とうろく:registered:N2}される[危険]{きけん:risk:N3}があります。[freee]{ふりー:freee}では[外部]{がいぶ:external:N3}[システム]{しすてむ:system}の[取引]{とりひき:transaction:N3}IDを[冪等性]{べきとうせい:idempotency:N1}キーとして[ユニーク]{ゆにーく:unique}[制約]{せいやく:constraint:N3}を[掛ける]{かける:to apply:N3}ことで、[何]{なん:what:N5}[度]{ど:times:N4}リクエストが[届いて]{とどいて:to arrive:N2}も[結果]{けっか:result:N1}が[一]{ひと:one:N5}つに[収束]{しゅうそく:converge:N3}するように[設計]{せっけい:design:N2}されています。\n\n#en\nWhen importing data from bank APIs or payment services, there is a risk that the same transaction could be registered twice due to network failures or retries. freee applies a unique constraint on the external system's transaction ID as an idempotency key, designed so that no matter how many times a request arrives, the result converges to a single posting.\n::\n\n::heading\n[監査]{かんさ:audit:N1}[証跡]{しょうせき:trail:N1}の[設計]{せっけい:design:N2}\n\n#en\nAudit Trail Design\n::\n\n::para\n[会計]{かいけい:accounting:N4}データは[編集]{へんしゅう:edit:N2}や[削除]{さくじょ:delete:N1}されても、その[履歴]{りれき:history:N1}が[完全]{かんぜん:complete:N3}に[残る]{のこる:to remain:N3}[必要]{ひつよう:needed:N3}があります。[freee]{ふりー:freee}は[追記]{ついき:append:N3}[専用]{せんよう:only:N2}のイベントログを[採用]{さいよう:adopt:N2}し、すべての[変更]{へんこう:change:N3}を[不変]{ふへん:immutable:N3}な[形]{かたち:form:N3}で[保持]{ほじ:retain:N1}します。[誰]{だれ:who:N3}が、いつ、どの[フィールド]{ふぃーるど:field}を、どの[値]{あたい:value:N3}から、どの[値]{あたい:value:N3}に[変えた]{かえた:changed:N3}かが[後]{あと:after:N5}から[完全]{かんぜん:complete:N3}に[再現]{さいげん:reproduce:N2}できることが[監査]{かんさ:audit:N1}[対応]{たいおう:compliance:N1}の[前提]{ぜんてい:precondition:N1}です。\n\n#en\nEven when accounting data is edited or deleted, its history must remain completely. freee adopts append-only event logs and retains all changes in immutable form. The ability to fully reproduce later who changed which field, when, and from what value to what value is the precondition of audit compliance.\n::\n\n::callout\n「データを[消す]{けす:to delete:N3}」のではなく「[削除]{さくじょ:delete:N1}されたという[事実]{じじつ:fact:N3}を[追加]{ついか:add:N3}する」のが[会計]{かいけい:accounting:N4}システムの[鉄則]{てっそく:iron rule:N2}です。\n\n#en\n\"Add the fact that it was deleted\" rather than \"delete the data\" — this is the iron rule of accounting systems.\n::\n\n::heading\n[締め]{しめ:closing:N1}[後]{ご:after:N5}の[遡及]{そきゅう:retroactive:N1}[修正]{しゅうせい:correction:N1}\n\n#en\nRetroactive Corrections After Period Close\n::\n\n::para\n[月次]{げつじ:monthly:N3}や[年次]{ねんじ:annual:N3}の[締め]{しめ:closing:N1}が[終わった]{おわった:ended:N4}[後]{あと:after:N5}に[誤り]{あやまり:error:N3}が[見つかる]{みつかる:to be found:N5}こともあります。[既に]{すでに:already:N1}[確定]{かくてい:finalized:N3}した[期]{き:period:N3}を[直接]{ちょくせつ:directly:N2}[書き換える]{かきかえる:to rewrite:N2}ことは[禁止]{きんし:forbidden:N2}され、[代わり]{かわり:instead:N4}に「[修正]{しゅうせい:correction:N1}[仕訳]{しわけ:journal:N1}」を[当期]{とうき:current period:N3}に[追加]{ついか:add:N3}するのが[正しい]{ただしい:correct:N4}[処理]{しょり:handling:N3}です。[freee]{ふりー:freee}では[締め]{しめ:closing:N1}[ロック]{ろっく:lock}[機能]{きのう:feature:N3}によって[過去]{かこ:past:N3}の[期間]{きかん:period:N3}への[書き込み]{かきこみ:write:N3}を[排他]{はいた:exclusion:N1}し、[修正]{しゅうせい:correction:N1}は[必ず]{かならず:always:N3}[新しい]{あたらしい:new:N4}[仕訳]{しわけ:journal:N1}として[記録]{きろく:recorded:N2}されます。\n\n#en\nErrors are sometimes found after monthly or annual closings have ended. Directly rewriting an already-finalized period is forbidden; instead, the correct handling is to add a \"correction journal entry\" in the current period. freee's closing-lock feature excludes writes to past periods, and corrections are always recorded as new journal entries.\n::\n\n::heading\nバッチ[照合]{しょうごう:reconciliation:N2}による[二重]{にじゅう:double:N4}チェック\n\n#en\nDouble-Checking via Batch Reconciliation\n::\n\n::para\n[書き込み]{かきこみ:write:N3}[時]{じ:time:N5}の[検証]{けんしょう:verification:N1}に[加え]{くわえ:in addition:N3}、[freee]{ふりー:freee}は[夜間]{やかん:nightly:N4}バッチで[全]{ぜん:all:N3}テナントの[勘定]{かんじょう:account:N1}[残高]{ざんだか:balance:N3}を[再計算]{さいけいさん:recalculate:N2}し、[既存]{きそん:existing:N1}の[残高]{ざんだか:balance:N3}テーブルと[突き合わせ]{つきあわせ:to compare against:N3}ます。[差分]{さぶん:difference:N3}が[発生]{はっせい:occur:N4}した[場合]{ばあい:case:N3}は[即座]{そくざ:immediate:N1}にアラートを[飛ばし]{とばし:to send:N3}、[原因]{げんいん:cause:N3}を[追跡]{ついせき:trace:N2}します。これは「[書き込み]{かきこみ:write:N3}[経路]{けいろ:path:N3}にバグがあっても[気付ける]{きづける:can notice:N3}」ための[最後]{さいご:last:N3}の[砦]{とりで:fortress:N1}です。\n\n#en\nIn addition to write-time verification, freee runs a nightly batch that recalculates account balances for all tenants and compares them against the existing balance table. When a difference occurs, an alert fires immediately and the cause is traced. This is the last line of defense to \"notice even when there is a bug in the write path.\"\n::\n\n::heading\n[リコンサイル]{りこんさいる:reconcile}[失敗]{しっぱい:failure:N3}[時]{じ:time:N5}の[運用]{うんよう:operation:N4}\n\n#en\nOperations When Reconciliation Fails\n::\n\n::para\n[照合]{しょうごう:reconciliation:N2}で[差分]{さぶん:difference:N3}が[出た]{でた:emerged:N5}[場合]{ばあい:case:N3}、[安易]{あんい:thoughtless:N3}に[残高]{ざんだか:balance:N3}テーブルを[書き換える]{かきかえる:to rewrite:N2}ことは[絶対]{ぜったい:absolutely:N3}に[避け]{さけ:to avoid:N1}ます。[必ず]{かならず:always:N3}[原因]{げんいん:cause:N3}となった[仕訳]{しわけ:journal:N1}を[特定]{とくてい:identify:N3}し、[正規]{せいき:normal:N3}の[修正]{しゅうせい:correction:N1}フローで[修復]{しゅうふく:repair:N1}します。[人]{ひと:human:N5}による[手]{て:hand:N4}[作業]{さぎょう:work:N4}を[挟む]{はさむ:to insert:N2}ほど、データの[一貫性]{いっかんせい:consistency:N1}が[損なわれる]{そこなわれる:to be impaired:N2}リスクが[高まる]{たかまる:to rise:N5}からです。\n\n#en\nWhen a reconciliation difference appears, thoughtlessly rewriting the balance table is absolutely avoided. The journal entry causing the discrepancy is always identified and repaired through the normal correction flow. The more manual intervention is inserted, the higher the risk that data consistency is impaired.\n::\n\n::heading\n[テナント]{てなんと:tenant}ごとの[排他]{はいた:exclusion:N1}[制御]{せいぎょ:control:N3}\n\n#en\nPer-Tenant Exclusion Control\n::\n\n::para\n[同じ]{おなじ:same:N4}[勘定]{かんじょう:account:N1}に[対する]{たいする:against:N3}[同時]{どうじ:simultaneous:N4}[書き込み]{かきこみ:write:N3}を[安全]{あんぜん:safely:N3}に[捌く]{さばく:to handle:N1}ため、[freee]{ふりー:freee}は[テナント]{てなんと:tenant}IDと[勘定]{かんじょう:account:N1}IDを[キー]{きー:key}とする[行]{ぎょう:row:N5}[ロック]{ろっく:lock}を[使い]{つかい:to use:N4}ます。[残高]{ざんだか:balance:N3}[更新]{こうしん:update:N3}は[必ず]{かならず:always:N3}この[ロック]{ろっく:lock}を[取った]{とった:acquired:N3}[後]{あと:after:N5}に[行わ]{おこなわ:performed:N5}れ、[読み取り]{よみとり:read:N3}と[書き込み]{かきこみ:write:N3}の[間]{あいだ:between:N5}に[割り込み]{わりこみ:interruption:N3}が[入って]{はいって:to enter:N5}も[結果]{けっか:result:N1}が[壊れない]{こわれない:not broken:N1}ように[設計]{せっけい:design:N2}されています。\n\n#en\nTo safely handle simultaneous writes to the same account, freee uses row locks keyed by tenant ID and account ID. Balance updates are always performed after acquiring this lock, designed so that even if interruptions occur between read and write, the result is not broken.\n::\n\n::heading\nおわりに\n\n#en\nConclusion\n::\n\n::para\n[freee]{ふりー:freee}の[整合性]{せいごうせい:integrity:N1}[戦略]{せんりゃく:strategy:N2}は[一]{ひと:one:N5}つの[銀の]{ぎんの:silver:N4}[弾丸]{だんがん:bullet:N1}ではなく、「[書き込み]{かきこみ:write:N3}[時]{じ:time:N5}[検証]{けんしょう:verify:N1}」「[冪等性]{べきとうせい:idempotency:N1}キー」「[追記]{ついき:append:N3}[専用]{せんよう:only:N2}[監査]{かんさ:audit:N1}ログ」「[締め]{しめ:closing:N1}[ロック]{ろっく:lock}」「[夜間]{やかん:nightly:N4}[再]{さい:re-:N2}[計算]{けいさん:calculation:N2}」という[多]{た:multi-:N4}[層]{そう:layer:N2}の[防御]{ぼうぎょ:defense:N2}の[組み合わせ]{くみあわせ:combination:N3}です。[金融]{きんゆう:financial:N1}データを[扱う]{あつかう:to handle:N1}システムでは、[一]{ひと:one:N5}つの[層]{そう:layer:N2}が[失敗]{しっぱい:fail:N3}しても[他の]{ほかの:other:N3}[層]{そう:layer:N2}が[捕捉]{ほそく:catch:N1}できる[多重]{たじゅう:multi:N4}[防御]{ぼうぎょ:defense:N2}が[必須]{ひっす:essential:N1}です。\n\n#en\nfreee's integrity strategy is not a single silver bullet, but a combination of layered defenses: write-time verification, idempotency keys, append-only audit logs, closing locks, and nightly recalculation. In systems handling financial data, multi-layered defense — where other layers can catch failures even if one layer fails — is essential.\n::\n",{"id":118,"title":121,"titleEn":122,"topicPath":10,"questions":123},"テック確認テスト — データ整合性とマルチテナント","Tech Check Quiz — Data Integrity and Multi-Tenancy",[124,151,174,197,222,246],{"id":125,"articleId":6,"question":126,"options":129,"correctLabel":135,"explanation":146,"tags":149},"tech-data-architecture-quiz-q01",{"en":127,"jp":128},"Which is the most appropriate policy for guaranteeing double-entry bookkeeping integrity at freee?","freeeで複式簿記の整合性を担保するうえで、もっとも適切な方針はどれか。",[130,134,138,142],{"label":131,"jp":132,"en":133},"ア","夜間バッチで整合性を検証し、書き込み時は無検証で速度を優先する。","Verify integrity in nightly batches and prioritize speed by skipping write-time checks.",{"label":135,"jp":136,"en":137},"イ","書き込みトランザクション内で借方合計と貸方合計の一致をDB制約とアプリ層の両方で検証する。","Verify debit-credit equality at both DB constraint and application layer within the write transaction.",{"label":139,"jp":140,"en":141},"ウ","顧客に手動で残高を確認させ、不整合が出たら通知してもらう。","Have customers manually verify balances and report discrepancies.",{"label":143,"jp":144,"en":145},"エ","仕訳ごとにユニークIDを発行するだけで、合計検証は不要にする。","Issue a unique ID per journal entry and skip total verification.",{"en":147,"jp":148},"Integrity must always be verified at write time. Multi-layered defense across the app layer and DB constraint is basic; nightly batches are an additional fortress.","整合性は書き込み時に必ず検証することが鉄則。アプリ層とDB制約の多層防御が基本。夜間バッチは追加の砦として併用する。",[18,150],"integrity",{"id":152,"articleId":6,"question":153,"options":156,"correctLabel":135,"explanation":169,"tags":172},"tech-data-architecture-quiz-q02",{"en":154,"jp":155},"When the same transaction data arrives from a bank API multiple times, which approach does freee take to prevent double-posting?","銀行APIから同じ取引データが複数回送られてきた場合、二重計上を防ぐためにfreeeが採る手法はどれか。",[157,160,163,166],{"label":131,"jp":158,"en":159},"受信時刻でソートし、最新だけを採用する。","Sort by receive time and adopt only the latest.",{"label":135,"jp":161,"en":162},"外部システムの取引IDを冪等性キーとしてユニーク制約を掛ける。","Apply a unique constraint on the external transaction ID as an idempotency key.",{"label":139,"jp":164,"en":165},"金額が同じ取引はすべて自動的に削除する。","Automatically delete all transactions with the same amount.",{"label":143,"jp":167,"en":168},"重複は許容し、後でユーザーに削除させる。","Allow duplicates and have the user delete them later.",{"en":170,"jp":171},"Using the external system's transaction ID as a unique-constrained idempotency key ensures the result converges to one even if retries occur.","外部システムが発行する取引IDをユニーク制約付きの冪等性キーとして使うことで、再試行が起きても結果が一つに収束する。",[44,173],"fintech",{"id":175,"articleId":6,"question":176,"options":179,"correctLabel":139,"explanation":192,"tags":195},"tech-data-architecture-quiz-q03",{"en":177,"jp":178},"Which is the correct design for an audit trail?","監査証跡として正しい設計はどれか。",[180,183,186,189],{"label":131,"jp":181,"en":182},"古い値を上書きし、最新の状態だけ保持する。","Overwrite old values and keep only the latest state.",{"label":135,"jp":184,"en":185},"削除時はレコード自体を物理削除する。","Physically delete the record itself on deletion.",{"label":139,"jp":187,"en":188},"追記専用のイベントログにすべての変更を不変な形で記録する。","Record all changes in immutable form to an append-only event log.",{"label":143,"jp":190,"en":191},"監査ログは一年で自動削除し、ストレージを節約する。","Auto-delete audit logs after one year to save storage.",{"en":193,"jp":194},"Rather than 'deleting data,' 'adding the fact of deletion' is the iron rule of accounting systems. Append-only logs are required so that who changed what and when can be fully reproduced.","「データを消す」のではなく「削除という事実を追加する」のが会計システムの鉄則。追記専用ログで誰がいつ何を変えたかを完全に再現できる必要がある。",[48,196],"immutability",{"id":198,"articleId":199,"question":200,"options":203,"correctLabel":135,"explanation":216,"tags":219},"tech-data-architecture-quiz-q04","tech-mf-multitenant",{"en":201,"jp":202},"Which best describes Money Forward's multi-tenant isolation strategy?","Money Forwardが採るマルチテナント分離戦略の説明として最も適切なものはどれか。",[204,207,210,213],{"label":131,"jp":205,"en":206},"全顧客を必ず同じ行レベル分離で扱い、運用負荷を最小化する。","Always handle all customers with row-level isolation to minimize operational load.",{"label":135,"jp":208,"en":209},"プロダクト特性に応じて行レベル分離とスキーマ・専用クラスタ隔離を使い分ける。","Use row-level isolation and schema\u002Fdedicated-cluster isolation selectively per product characteristic.",{"label":139,"jp":211,"en":212},"セキュリティを最優先し、必ずテナントごとに別物理サーバを与える。","Always give each tenant a separate physical server, prioritizing security.",{"label":143,"jp":214,"en":215},"データ分離はアプリ層に任せ、DB側では一切制約を掛けない。","Leave isolation entirely to the app layer and apply no DB-side constraints.",{"en":217,"jp":218},"There is no silver bullet — both row-level and schema-level approaches are used selectively, and large customers are isolated to dedicated clusters.","銀の弾丸はなく、行レベルとスキーマレベルの両方を製品特性に応じて使い分け、大口顧客は専用クラスタへ隔離する。",[220,221],"multitenant","isolation",{"id":223,"articleId":199,"question":224,"options":227,"correctLabel":135,"explanation":240,"tags":243},"tech-data-architecture-quiz-q05",{"en":225,"jp":226},"Which design is required to safely handle multi-tenancy with shared caches (e.g. Redis)?","共有キャッシュ（Redisなど）でマルチテナントを安全に扱うために必要な設計はどれか。",[228,231,234,237],{"label":131,"jp":229,"en":230},"テナントIDをキーに含めず、すべてのテナントでキャッシュを共有する。","Omit tenant IDs from keys and share cache entries across all tenants.",{"label":135,"jp":232,"en":233},"すべてのキャッシュキーにテナントプレフィックスを強制し、ライブラリ層で誤用を防ぐ。","Enforce a tenant prefix on every cache key and prevent misuse at the library layer.",{"label":139,"jp":235,"en":236},"キャッシュは無効化し、すべて毎回DBから読む。","Disable caches and always read from the DB.",{"label":143,"jp":238,"en":239},"テナントごとに別Redisインスタンスを必ず立てる。","Always provision a separate Redis instance per tenant.",{"en":241,"jp":242},"Omitting tenant IDs from cache keys causes a fatal bug where other tenants' data is returned. Enforcing prefixes and library-layer guards is fundamental.","テナントIDをキーから外すと他テナントのデータが返る致命的バグが発生する。プレフィックス強制とライブラリ層のガードが基本。",[244,245],"cache","security",{"id":247,"articleId":199,"question":248,"options":251,"correctLabel":135,"explanation":264,"tags":267},"tech-data-architecture-quiz-q06",{"en":249,"jp":250},"Which is the most appropriate countermeasure for the 'noisy neighbor' problem?","「騒がしい隣人問題（noisy neighbor）」への対策として最も適切なのはどれか。",[252,255,258,261],{"label":131,"jp":253,"en":254},"全テナントに同じ性能を保証するため、負荷の高いテナントもそのまま放置する。","Leave high-load tenants alone since all tenants must get equal performance.",{"label":135,"jp":256,"en":257},"テナントごとのリクエストレート・同時接続数・CPU時間に上限を設ける。","Set per-tenant upper limits on request rate, concurrent connections, and CPU time.",{"label":139,"jp":259,"en":260},"問題が出たら手動で当該テナントを完全に停止する。","Manually stop the offending tenant entirely when problems arise.",{"label":143,"jp":262,"en":263},"アプリケーション層では何もせず、ハードウェアの増強だけで対応する。","Do nothing at the app layer and address it only by adding hardware.",{"en":265,"jp":266},"Setting per-tenant limits on request rate, concurrent connections, and CPU time prevents one tenant from pressuring overall performance. Extremely large customers are isolated to dedicated clusters.","リクエストレート・同時接続数・CPU時間に上限を設けることで一テナントが全体性能を圧迫することを防ぐ。極端に大きい顧客は専用クラスタへ隔離する。",[220,268],"resource-quota"]